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Executive  Summary 

ENGINEERING  SUPPLY  MANAGEMENT  SYSTEM 
The  Next  Generation 


The  U.S.  Army  Engineering  and  Housing  Support  Center  (USAEHSC)  is 
modernizing  the  Facility  Engineering  Supply  System  (FESS)  used  by  those 
Directorates  or  Divisions  of  Engineering  and  Housing  (DEHs)  that  managed  real 
property  maintenance  supplies  in  house.  The  decision  to  upgrade  FESS  is  based  on 
the  inability  of  the  software  to  satisfy  current  system  requirements,  high  yearly 
maintenance  costs,  and  outdated  system  hardware. 

We  found  that  the  lowest  life-cycle-cost  alternative  for  modernizing  the  FESS  is 
to  modify  an  existing  personal  computer  (PC)-based  system  already  owned  by  the 
Army,  or  if  identified  candidates  cannot  be  cost-effectively  modified  in  accordance 
with  standard  Army  multicommand  management  information  system  requirements, 
to  develop  an  entirely  new  system.  The  additional  costs  to  procure  and  license  an 
existing  private-sector  system  far  exceed  any  functional  advantages  and  any 
alternative  that  moves  or  upgrades  existing  FESS  software  to  different  computer 
hardware  is  not  cost-effective.  Adopting  a  PC-based  system  has  the  added  benefit  of 
improved  system  expandability,  flexibility,  and  better  control. 

We  recommend  that  USAEHSC  take  the  following  actions  to  minimize  the 
life-cycle  costs  of  implementing  the  next-generation  supply  management  system  used 
by  DEHs. 

•  Adapt  an  existing  PC-based  supply  management  system  or,  if  acquiring  an 
existing  system  proves  impractical,  develop  a  comparable  system  that  is 
compatible  with  UNIX  and  disk  operating  system  environments,  supported 
by  a  relational-type  database  and  standard  query  language,  and  written  in  a 
fourth-generation  programming  language.  Based  on  our  initial  investi¬ 
gations,  the  Corps  of  Engineers  Computer-Aided,  Supply  Transaction, 
Logistics  Environment  appears  to  be  an  example  of  an  existing  system  that 
USAEHSC  could  modify. 
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•  Complete  a  detailed  requirements  analysis  of  the  proposed  system  to  ensure 
that  the  next-generation  system  fully  supports  the  Army’s  needs,  design  and 
program  the  system,  and  implement  it  in  a  timely  manner  to  minimize  costs. 
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CHAPTER  1 


INTRODUCTION 


BACKGROUND 

Materials  and  equipment  used  for  real  property  maintenance  activity  (RPMA) 
work,  which  includes  construction,  maintenance,  and  repair,  are  for  the  most  part, 
peculiar  to  the  Directorates  or  Divisions  of  Engineering  and  Housing  (DEH)  and  are 
required  in  sufficient  on-hand  quantities  to  ensure  responsiveness  to  the  DEH’s 
primary  mission.  As  a  result,  DEHs  procure  and  store  their  own  inventories  of 
RPMA  materials  and  equipment  at  DEH-controlled  warehouses,  shops,  and  self-help 
centers.!  Most  RPMA  materials  are  procured  through  the  Government’s  wholesale 
supply  system  or  by  local  purchases.  More  than  10  years  ago,  DEHs  around  the  world 
began  using  an  automated  information  system  called  the  Facility  Engineering 
Supply  System  (FESS)  to  help  manage  their  supplies.  FESS  is  still  fully  operational 
and  considered  by  many  in  the  field  to  be  a  useful  DEH  automated  system. 

Facility  Engineering  Supply  System  Configuration 

The  FESS  is  an  automated  inventory  control  and  supply  management  system 
that  improves  material  security,  reduces  the  need  for  manual  stock  control,  simplifies 
financial  accounting,  and  accumulates  necessary  management  information  for 
periodic  reporting.  The  nature  of  supply  operations  in  today’s  Army  precludes  stand¬ 
alone  systems.  Therefore,  over  the  past  10  years  FESS  has  been  upgraded  to 
interface  with  a  number  of  Army  and  DoD  automated  systems.  For  the  most  part, 
these  interfaces  are  accomplished  by  batch  processing  on  magnetic  tape  transfers. 
For  example,  FESS  has  a  batch  interface  to  the  Standard  Army  Intermediate  Level 
Supply  (SAILS)  system  for  Army  stock  fund  accounting  requirements,  with  the 
Integrated  Facilities  System-Increment  I  (IFS-I)  for  job  order  accounting  and 
scheduling,  and  with  the  Standard  Army  Financial  System  (STANFINS)  for  finance 
and  accounting.  Each  of  these  other  systems  is  currently  being  considered  for 


•DEHs  at  Army  Materiel  Command  (AMC)  installations  normally  operate  under  a  central 
supply  concept  implemented  by  the  Directorate  of  I.ogistics  (DOL)  and  therefore  are  customers  of  the 
installations'  supply  activities. 
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modification  and  will  be  replaced  or  upgraded  in  the  near  future.  As  a  result,  if  FESS 
continues  to  be  the  DEH’s  automated  supply  management  system,  it  will  need  to  be 
reprogrammed  to  support  continued  information  exchange  with  these  other  systems. 

The  FESS  contains  over  200  files  and  150,000  lines  of  code.  About  60  percent  of 
the  FESS  software  is  written  in  a  Motorola  proprietary  programming  language  called 
VISION,  the  remainder  is  programmed  in  common  business  oriented  language 
(COBOL).  The  current  FESS  is  an  on-line  system  and  is  supported  by  a  custom 
database.  In  its  current  configuration,  it  and  the  Motorola  FV  Phase  minicomputer 
support  more  than  30  work  stations  networked  in  a  distributed  configuration  and 
handle  between  200  and  2,000  transactions  a  day  —  depending  on  location.  In  order 
to  keep  FESS  up  to  date,  the  Army  spends  over  $500,000  a  year  on  software 
maintenance  alone. 

The  FESS  still  runs  on  its  original  computer  platform,  the  Motorola  IV  Phase 
minicomputer.  Over  the  past  10  years,  the  IV  Phase  computer’s  role  has  expanded 
because  other  systems  have  been  added  to  the  platform  such  as  the  Facilities 
Engineering  Job  Estimating  (FEJE)  system  and  the  Integrated  Facilities  Data  Entry 
Process  (IFDEP),  a  front-end  data-loading  system  to  the  IFS.  As  a  result,  FESS  had 
to  share  processing  time  with  those  other  systems.  The  FV  Phase  computer  has 
1.5  Mbytes  of  memory  and  can  support  fixed-storage  drives  ranging  from  67.5  to 
570  Mbytes.  The  U.S.  Army  Engineering  and  Housing  Support  Center  (USAEHSC) 
currently  spends  about  $1.8  million  a  year  through  a  third-party  contract  to  maintain 
the  Motorola  FV  Phase  hardware.  The  current  contract  expires  in  September  1994. 

IFS-M  Architecture 

The  USAEHSC  is  currently  implementing  the  DEH’s  new  RPMA  management 
system.  Integrated  Facilities  System-Mini/Micro  (IFS-M).  IFS-M  will  act  as  a 
common  hardware/software  platform  upon  which  RPMA  information  systems, 
including  supply  management,  can  operate  as  stand-alone  systems.  At  the  same 
time,  because  of  the  ease  of  intersystem  communications,  IFS-M  can  interface  with 
all  other  DEH  applications.  Systems  such  as  IFS-I,  FEJE,  and  IFDEP  will  no  longer 
be  stand-alone  when  IFS-M  is  deployed  since  the  functions  these  systems  support  will 
be  programmed  into  IFS-M.  IFS- M’s  system  architecture  was  designed  for  flexibility 
and  is  currently  capable  of  boundless  future  expansion. 


Because  IFS-M  will  contain  the  DEH’s  database  of  record,  it  is  important  to 
recognize  the  system’s  architecture  since  the  supply  system  will  essentially  operate 
within  IFS-M’s  system  framework.  Originally,  the  fully  deployed  IFS-M  system  was 
intended  to  include  a  new  supply  management  system  module  (or  an  interface  with  a 
redesigned  FESS)  that  was  to  be  fully  integrated  into  all  of  IFS-M’s  other  modules. 
However,  fresh  ideas  and  lack  of  resources  have  precluded  the  full  development  of 
such  a  module. 

Since  some  information  contained  in  IFM’s  databases  must  be  shared  with  other 
Army  and  DoD  systems,  a  number  of  required  FESS  interfaces  have  already  been 
written  for  IFS-M.  This  means  that  the  new  automated  supply  system  can  simply  use 
IFS-M  as  its  gateway  to  these  other  systems,  which  would  significantly  reduce  the 
time  necessary  to  continually  program  duplicate  interfaces. 

The  IFS-M  runs  on  the  Sperry  5000-series  minicomputers  and  is  programmed  in 
ORACLE,  a  fourth-generation  language  (4GL)  supported  by  a  relational  database 
that  is  standard  query  language  (SQL)-compatible.  By  "relational”  we  mean  a  series 
of  two-way  tables  that  can  be  easily  linked  together  in  an  infinite  variety  of  data 
relationships,  allowing  maximum  information  flexibility  and  accessibility.  SQL  is 
the  accepted  national  standard  (and  fast  becoming  the  Army  standard)  for  accessing 
data  in  a  relational  database,  which  once  written,  can  be  used  on  any  hardware  and 
any  relational  database  software.  Systems  that  do  not  comply  with  this  requirement 
or  are  not  planned  for  this  future  enhancement  will  not  be  considered  further.  It  is 
essential  that  systems  interfacing  with  IFS-M  operate  in  a  UNIX  or  disk  operating 
system  (DOS)  environment. 

PROBLEM  STATEMENT 

Recently,  FESS  has  been  criticized  because  it  is  over  10  years  old,  is  expensive 
to  maintain,  needs  functional  upgrades  to  fully  satisfy  users’  needs,  and  is  unable  to 
take  advantage  of  software  and  hardware  technology  that  can  now  make  system 
improvements  possible  at  relatively  low  cost.  In  response  to  that  criticism, 
USAEHSC  assembled  a  team  of  technical  and  functional  supply  management 
professionals  to  redesign  and  improve  FESS.  Following  the  same  development 
methodology  used  to  create  IFS-M,  the  team  used  a  structured  systems  requirements 
analysis  to  model  the  next-generation,  DEH,  automated  supply  management  system. 
The  team  identified  more  than  20  areas  in  which  FESS  could  be  improved,  developed 
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a  conceptual  data  model  of  the  proposed  system,  and  specified  the  system’s  detailed 
requirements.  At  the  time,  the  team  recognized  that  even  the  20  improvement 
opportunities  did  not  fully  identify  all  needed  enhancements.  The  projected  cost  to 
totally  redesign  and  reprogram  FESS  prompted  USAEHSC  to  investigate  other 
appropriate  and  cost-effective  strategies  that  would  generate  the  same  proposed 
supply  system  modeled  during  the  detailed  requirements  analysis.  It  arrived  at  four 
alternatives:  designing  and  programming  a  new  automated  supply  management 
system  from  scratch,  porting  and  upgrading  existing  FESS  software  to  a  new 
hardware  platform,  upgrading  FESS  on  its  existing  hardware,  and 
modifying/upgrading  an  existing  automated  supply  management  system  previously 
developed  by  another  Government  agency  or  a  private-sector  company. 

STUDY  APPROACH 

The  Logistics  Management  Institute  (LMI)  was  tasked  to  evaluate  USAEHSC’s 
four  options.  LMI  identified  and  analyzed  automated  supply  management  systems 
used  by  the  other  Services  and  Government  agencies,  while  the  Construction 
Engineering  Research  Laboratory  (CERL)  conducted  research  into  private-sector 
systems.  So  that  the  results  of  the  two  separate  studies  would  be  comparable,  CERL 
used  LMI’s  systems  evaluation  methodology  as  discussed  below. 

The  goal  of  this  study  is  to  determine  the  least-cost  solution  to  USAEHSC.  We 
analyzed  the  existing  systems  that  come  closest  to  satisfying  the  DEH’s  supply 
management  requirements  to  determine  whether  modifying  an  existing  system 
would  be  more  cost-effective  than  modifying  FESS  or  programming  from  scratch. 
The  decisions  are  based  on  a  least-cost  determination  of  the  alternatives’  life  cycles. 
We  determined  how  well  the  existing  systems  comply  with  the  proposed  system’s 
requirements  and  what  it  would  cost  to  modify  them  to  make  them  comply  fully.  The 
cost  to  implement  and  maintain  the  proposed  systems  was  added  to  the  modification 
cost  to  obtain  a  total  life-cycle  cost. 

To  calculate  the  life-cycle  costs  of  modifying  existing  systems,  we  started  with 
the  set  of  well-defined  detailed  system  requirements  produced  by  a  team  of  Army 
technical  experts,  functional  experts,  and  installation-level  users.  We  di^  ided  the 
requirements  into  functional  and  technical  requirements  and  then  further  divided 
them  into  meaningful  categories  to  establish  an  organized  list  of  system 
requirements.  Because  each  unique  requirement  is  not  equally  important  to  the 
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overall  success  of  the  proposed  system,  the  requirements  were  weighted  according  to 
their  relative  importance.  The  technique  used  to  compute  the  relative  importance  of 
each  requirement  is  called  the  analytic  hierarchical  process  (AHP).  In  that  process, 
opinions  and  judgments  are  solicited  from  a  group  of  experts  and  the  results  are 
quantified  using  a  series  of  mathematical  algorithms.  We  used  the  AHP  technique  at 
a  conference  conducted  at  LMI  with  a  team  of  Army  experts.  A  software  package 
called  "Expert  Choice,”  which  incorporates  the  AHP,  was  used  to  facilitate  the 
procedures.  When  the  process  was  complete,  the  team  had  determined  relative 
weights  —  totaling  100  percent  —  for  both  the  list  of  technical  and  functional  system 
requirements.  Some  of  these  requirements  were  considered  so  important  that  if  the 
candidate  system  could  not  satisfy  them,  it  would  no  longer  be  considered  a 
candidate;  those  criteria  were  given  an  "infinite”  weighting.  The  weighted  list  of 
requirements  then  became  the  "yardstick”  that  could  be  used  to  measure  how  well 
existing  supply  management  systems  met  the  proposed  system’s  requirements. 
Appendix  A  describes  each  of  the  functional  and  technical  criteria  as  we  interpreted 
them  for  this  study. 

After  the  list  of  system  requirements  had  been  ranked,  LMI  identified  existing 
supply  management  systems  from  the  Navy,  Air  Force,  Defense  Logistics  Agency 
(DLA),  the  Army  Corps  of  Engineers,  and  the  AMC.  Meanwhile,  the  CERL 
concentrated  on  the  private-sector  candidates.  Since  it  was  unlikely  that  any  single 
system  would  comply  totally  with  all  requirements,  each  candidate’s  compliance  was 
measured  on  a  0  to  5  scale2.  Of  the  systems  we  evaluated,  those  with  the  highest 
aggregate  weighted  scores  were  considered  the  strongest  contenders,  and  we 
analyzed  them  for  life-cycle  costs.  The  final  selection  of  all  the  candidate  systems  was 
based  on  lowest  life-cycle  costs  which  were  then  compared  to  the  other  alternatives  — 
upgrading  FESS  on  its  existing  platform  or  porting  FESS  to  new  hardware.  The 
weights  assigned  for  each  requirement  are  shown  in  Table  1-1. 

REPORT  ORGANIZATION 

The  remainder  of  this  report  provides  the  results  from  our  analysis  of  the 
alternatives.  Chapter  2  gives  a  brief  description  of  each  of  the  existing  Government 
and  private-sector  candidate  systems  and  provides  a  summary  of  the  results  of  the 
technical  and  functional  evaluations.  A  brief  description  of  the  proposed  functional 

“The  following  interpretation  of  the  scores  was  used:  .5  -  complies  totally,  4  =  complies  very 
well.  3  =  complies  fairly  well,  2  =  complies  poorly,  1  =  does  not  comply  or  cannot  comply 
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TABLE  1-1 


SYSTEM  REQUIREMENTS 


Technical  criteria 

Weight 

(percent) 

Functional  criteria 

Weight 

(percent) 

On-line  capability 

OCK* 

Report  generating  and  printing  capabilities 

0  035 

Required  database  management  system 

Stork  control  requirements 

Relational  database/SQL 

cz> 

Expanded  item  identification 

0  022 

System  files  maintenance 

00 

Stock  fund  war  reserves/freeze  codes 

0  010 

Ease  of  use/self-help  capability 

0  143 

Catalog  file 

0  114 

Canned  queries 

0011 

Replenishment  capability 

0  093 

Documentation 

0  033 

Add/drops 

0,021 

System  independence 

0071 

Physical  inventory  requirements 

System  security 

0  024 

Cyclic  inventories 

0  003 

Distributed  configuration 

cz> 

Inventory  worksheet 

0.025 

Required  interfaces 

Line-item/dolla  r-value  accounting 

0  028 

IFS-M 

00 

Seasonal/standby  items 

0  013 

S^ACONS 

0  048 

Spoilage/aging  inventory  display 

0  003 

Other  supply  information 

0019 

Picking/issuing  requirements 

SAILS/SARSS 

0  007 

Creates  pick  documents 

0,007 

Finance  and  accounting 

0  136 

Automatic  material  coordination  and 
equipment  control 

0  028 

Platform  independence 

0  368 

Automated  issue/return  slips 

0  052 

Scanning  capabilities 

Determining  picking  criteria 

0  003 

Bar-code  inputs 

0  028 

Receiving/putaway  requirements 

Optical  scanning  equipment 

0  028 

Generating  storage  documents 

0,01 1 

Imaging 

0  083 

Hot  tag  (receipt/issue) 

0  010 

Partial  receipts 

0  018 

Automatic  inventory  update 

0  048 

Discrepant  material 

0  004 

Order  processing  requirements 

Transaction  reversal  capability 

0012 

Document  register 

0  006 

MIL5TRIP  procedures 

0  052 

Transaction  register 

0  024 

Automatic  purchase  requisitions 

0  063 

Reconciliation 

0  009 

Job  cost  by  document,  phase,  and/or  facility 

0  288 

Total 

1  000 

Total 

1  000 

Note  r  A  r^r.tract'fq  Svst*»m  MILStrip  =  miMarv  standard  for  rpaui^it'onsnq  and  issue  p^'oc^c'  'es,  SQL  =  Standar.l  Query 

;  a''''>ja>.3P.  SAPSS  -  S’andard  Af'nv  »-  ta''  SuDO'Y 

<  n '•  r«! tpt ,  'e"*'' •';♦prl,^  o  ^  essential  t'r-rpf,;^  iT>ust  pn  r^et 
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and  technical  system  requirements  is  presented  in  Appendix  A,  and  the  detailed 
results  of  the  evaluations  are  provided  in  Appendix  B.  Chapter  3  provides  the  results 
of  the  life-cycle  cost  comparisons  of  modifying  the  existing  systems,  upgrading  and 
porting  FESS  to  new  hardware,  programming  an  entirely  new  system,  and  upgrading 
FESS  on  its  existing  hardware.  Appendix  C  provides  the  detailed  results  from  this 
analysis.  In  Chapter  4,  we  provide  our  conclusions  from  the  research  together  with 
our  recommendations  for  USAEHSC. 
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CHAPTER  2 


FUNCTIONAL  EVALUATION  OF  CANDIDATE  SYSTEMS 


Our  search  for  viable  candidates  from  other  Government  agencies  identified 
about  20  supply  management  systems.  We  reduced  the  field  of  viable  candidates  to 
10  after  eliminating  systems  that  were  near  the  end  of  their  useful  system  life,  that 
did  not  possess  required  functionality,  or  that  did  not  comply  with  one  or  more  of  the 
infinitely  weighted  criteria.  We  excepted  several  mainframe  systems  that  did  not 
meet  the  infinitely  weighted  criteria;  we  considered  them  further  because  of  their 
very  strong  functional  compliance  and  because  they  provided  a  baseline  for 
comparisons  against  the  other  systems.  The  supply  management  systems  described 
below  survived  the  initial  screening  process  and  comprise  the  set  of  viable  candidate 
systems. 

The  set  of  potential  supply  management  systems  from  the  private  sector  was 
much  larger.  An  automated  and  manual  search  (conducted  by  CERL)  identified  over 
1,400  candidate  systems.  However,  after  screening  those  systems  for  compliance 
with  the  infinitely  weighted  criteria,  the  number  of  candidates  was  reduced  to  a  more 
manageable  19  systems.  Any  one  of  those  19  systems  could  be  made  to  satisfy  all  the 
requirements,  and  the  vendors  were  willing  to  respond  to  proposals  to  modify  the 
systems;  however,  only  the  top  6  private-sector  systems  are  discussed  below. 

GOVERNMENT  SYSTEMS 

Standard  Base  Supply  System 

The  Air  Force’s  Standard  Base  Supply  System  (SBSS)  is  an  automated 
management  system  that  has  been  in  operation  since  1964.  It  runs  on  UNISYS  1 100- 
series  (soon  to  be  upgraded  to  2,400  series)  mainframe  computers  and  is  programmed 
in  COBOL  (version  1974,  soon  to  be  upgraded  to  the  1985  version).  The  system  batch 
processes  the  base  supply  information  and  is  not  supported  by  a  true  relational 
database  or  SQL.  We  also  found  that  the  system  is  not  very  user  friendly  compared  to 
other  systems  and  requires  some  knowledge  of  programming  languages  to  make 
ad  hoc  queries  of  the  database.  Upon  initial  inspection,  SBSS  appeared  a  strong 
candidate,  but  after  more  careful  analysis,  we  found  the  system  did  not  comply  with 
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many  of  the  proposed  technical  requirements  and  it  was  dropped  from  further 
consideration. 

Civil  Engineering  Material  Acquisition  System 

The  Civil  Engineering  Material  Acquisition  System  (CEMAS)  was  developed 
for  the  Air  Force  Base  Civil  Engineer  (BCE)  to  support  cost-effective  acquisition  of 
maintenance  and  repair  materials  from  Government  and  commercial  warehouses. 
CEMAS  runs  on  the  BCE’s  Wang  minicomputer  and  does  not  operate  in  a  UNIX  or 
DOS  environment.  Although  CEMAS  satisfies  many  of  the  functional  supply 
management  requirements  specified  by  the  Army,  it  is  not  supported  by  a  relational 
database  nor  SQL  and  does  not  run  in  a  distributed  configuration  environment. 

Medical  Stock  Control  System 

The  Medical  Stock  Control  System  (MEDSTOC)  is  an  automated  system 
developed  by  the  Army  Health  Services  Command  (HSC)  to  support  supply 
management.  MEDSTOC  runs  at  the  Army’s  regional  data  centers  on  Amdahl 
mainframe  computers  and  must  be  accessed  through  the  Army  Standard  Information 
Management  System  (ASIMS)  network.  MEDSTOC  batch  processes  information  and 
is  not  supported  by  a  relational  database  or  SQL.  We  found  that  MEDSTOC  was  not 
as  user  friendly  as  other  systems  we  examined,  but  it  did  perform  many  of  the 
functional  requirements.  MEDSTOC  is  currently  undergoing  system  modifications 
by  the  HSC. 

Warehouse  Inventory  Control  System 

The  Warehouse  Inventory  Control  System  (WIS)  is  an  on-line  automated  supply 
management  system  written  in  dBASE  IH  PLUS  (a  4GL).  WIS  was  developed  by  the 
U.S.  Army  Corps  of  Engineers  Portland  District  to  support  its  local  needs.  Currently, 
WIS  is  not  configured  to  run  in  a  distributed  environment  but  can  easily  be  made  to 
do  so.  WIS  can  run  on  IBM-compatible  personal  computers  (PCs)  on  any  DOS 
environment.  It  is  easy  to  use  but  does  not  have  an  extensive  self-help  capability. 
Although  WIS  was  designed  as  a  supply  management  system,  it  does  not  possess  as 
much  functionality  as  other  systems  we  considered.  However,  because  it  is  written  in 
a  4GL,  it  can  easily  be  made  to  comply  with  any  of  the  system  requirements. 
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Army  Materiel  Command  Installation  Supply  System 

The  AMC  Installation  Supply  System  (AMCISS)  is  the  AMC’s  installation-level 
automated  supply  management  system.  It  is  written  in  COBOL  1974  American 
National  Standards  Institute  (ANSI)-standard  which  makes  it  highly  dependent  on 
the  Amdahl/IBM  3090  hardware  running  at  the  Army’s  Regional  Data  Center. 
AMCISS  runs  under  the  MVS/CICS  operating  system  and  is  a  centralized  processing 
system  that  runs  on-line  through  remote  terminals  via  ASIMS.  The  database  is 
custom  designed  and  is  not  relational  and  not  SQL-compatible  (it  also  uses  a  custom- 
designed  query  language).  Although  AMCISS  does  not  pass  the  technical  criteria  on 
several  counts,  we  felt  it  deserved  a  closer  look  for  several  reasons.  First,  it  satisfied 
the  functional  requirements  as  well  as  any  of  the  other  systems  we  analyzed.  Second, 
AMC  is  considering  developing  a  corporate  database  into  which  AMCISS  information 
would  be  entered  nightly.  Third,  AMC  is  developing  PC  downloading  utilities,  which 
will  give  AMCISS  a  distributed  configuration  capability.  Finally,  AMC  is 
considering  converting  to  COBOL  El  programming  and  reverse  engineering  the 
system  to  reduce  the  quantity  of  code  (approximately  1.5  million  lines),  actions  that 
would  greatly  enhance  the  system’s  portability  to  other  hardware  platforms. 

Automated  Personal  Property  Management  System 

The  Automated  Personal  Property  Management  System  (APPMS)  is  the  new 
property  book  management  system  used  by  the  Army  Corps  of  Engineers.  The 
system  was  developed  by  a  contractor  out  of  the  Portland  District  and  will  soon 
become  the  Corps’  standard  property  book  management  system.  Although  from  a 
functional  point  of  view,  APPMS  is  not  a  good  supply  management  system,  it  has  a 
good  technical  system  configuration:  APPMS  is  written  in  FOXBASE-f-  (a  4GL), 
which  is  fully  compatible  with  a  relational  database  and  SQL;  it  is  a  PC-based  system 
that  runs  on  DOS  3.1  or  better;  it  is  capable  of  local  and  wide  area  networking  on 
NOVELL  systems;  and  it  is  an  on-line  system  that  is  user  friendly  with  an 
interactive  help  capability.  FOXPRO  allows  great  flexibility  in  ad  hoc  queries  (sorts 
and  searches)  and  report  generation  although  APPMS  already  has  a  number  of  useful 
canned  queries  programmed.  APPMS  does  not  currently  have  import/export  routines 
built  into  the  system  because  it  does  not  need  them  for  its  current  purpose,  but  its 
relational  database  and  SQL  capabilities  make  construction  of  any  required 
interfaces  relatively  easy. 
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Electronic  Point  of  Sale 


The  Naval  Supply  Systems  Command  has  implemented  the  Electronic  Point-of- 
Sale  (EPOS)  supply  management  system  at  a  number  of  Naval  Supply  Centers  to 
take  advantage  of  the  latest  PC  networking  technology  and  needed  supply 
management  improvements.  EPOS  was  developed  by  a  private-sector  contractor  and 
implemented  as  a  turnkey  system.  It  was  programmed  in  "C”  language  [a  third- 
generation  language  (3GL)]  and  uses  the  C-Tree  database  system,  which  is  fully 
relational.  EPOS  fully  utilizes  bar-code  technology  as  its  primary  form  of  system 
inputs.  It  is  an  on-line,  real-time  system  and  is  easy  to  use,  but  it  has  limited  self- 
help  capability.  Functionally,  it  complies  well  with  the  requirements  and  already 
has  programmed  most  of  the  canned  reports.  However,  its  ad  hoc  query  capability  is 
difficult  to  use.  Either  a  knowledgeable  C  programmer  must  create  the  query  or  the 
database  must  be  converted  to  American  Standard  Code  for  Information  Interchange 
(ASCII)  text  and  transferred  to  a  database  system  known  to  the  user  and  then 
manipulated  to  generate  the  required  reports.  The  system  already  has  a  number  of 
interfaces  written  to  the  Navy’s  finance  and  accounting,  contracting,  and  wholesale 
supply  system,  but  they  would  not  meet  the  Army’s  interface  needs. 

Computer-Aided  Supply  Transactions,  Logistics  Environment 

The  Computer-Aided  Supply  Transactions,  Logistics  Environment  (CASTLE)  is 
an  automated,  on-line,  distributed  system  developed  by  the  Army  Corps  of  Engineers 
New  Orleans  District  to  manage  inventory  at  its  supply  stores.  CASTLE  is  written  in 
dBASE  HI  PLUS  for  a  PC  network  environment,  operates  through  DOS,  and  is 
therefore  free  to  move  to  a  number  of  different  platforms.  The  dBASE  HI  PLUS 
closely  resembles  hierarchical  databases  although  it  is  not  currently  SQL-compatible 
(future  versions  of  dBASE  software  will  be  SQL-compatible).  We  found  CASTLE  to 
be  functionally  adequate,  user  friendly,  and  well  supported  by  pop-up,  self-help 
menus.  Since  it  is  a  4GL  system,  any  deficiencies  can  easily  be  overcome  through 
programming. 

Base  Operations  Support  System 

The  Base  Operations  Support  System  (BOSS)  runs  on  an  IBM  mainframe 
computer  (MVS  operating  system).  It  is  used  by  the  DLA  to  manage  inventory  that 
supports  all  base  operations.  BOSS  is  written  primarily  in  COBOL  language,  is  an 
on-line  system,  but  is  not  supported  by  a  relational  database  or  SQL.  BOSS  has  code 
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written  to  make  it  operate  like  a  distributed  configuration.  It  is  not  as  user  friendly 
as  some  other  systems  we  examined  but  is  supported  by  some  self-help  screens. 

Standard  Army  Retail  Supply  System 

The  Standard  Army  Retail  Supply  System  (SARSS)  is  the  Army’s  new  real¬ 
time,  retail-level  supply  management  system  that  will  replace  the  SAILS  system,  a 
batch  processing  system.  SARSS  automates  requisitioning,  receipt,  issue,  and 
storage  of  Army  materials  at  the  retail  level  and  was  implemented  to  improve 
responsiveness  of  all  aspects  of  supply  operations.  SARSS  was  designed  to  operate 
from  the  direct  support  unit  through  the  theater  or  major  command  level  in  both  the 
tactical-  and  installation-type  organizations.  However,  implementation  of  an 
installation-level  baseline  will  not  occur  until  1993,  at  the  earliest.  The  SARSS 
Branch  of  the  U.S.  Army  Combined  Arms  Support  Command  (CASCOM),  Deputy 
Chief  of  Staff  for  Logistics,  developed  and  is  responsible  for  maintaining  SARSS. 

The  SARSS  is  a  multilevel  system  that  divides  the  needed  functionality 
between  several  supporting  tiers  of  operation.  In  the  tactical  environment,  it  is 
written  in  standard  COBOL  for  Burroughs  tactical  minicomputers.  At  the  Corps 
level,  it  is  predominantly  written  in  INFORMIX,  a  fully  relational  4GL  database 
language  supported  by  SQL,  and  is  designed  to  run  on  the  Sperry  5000-series 
minicomputer.  The  installation-level  system,  when  completed,  will  pull  much  of  its 
needed  functionality  from  these  existing  levels  and  will  be  written  in  INFORMIX. 
However,  to  satisfy  the  current  needs  of  the  DEHs,  USAEHSC  will  have  to  modify 
SARSS  in  its  current  form,  which  means  that  the  needed  functionality  written  in 
COBOL  will  have  to  be  reprogrammed  in  INFORMIX.  Otherwise,  USAEHSC  will 
have  to  wait  until  the  installation  baseline  is  completed. 

PRIVATE-SECTOR  SYSTEMSl 

Argos  Business  Enterprise  Cost  Accounting  System 

The  Argos  Business  Enterprise  Cost  Accounting  System  (ABECAS)  is 
programmed  by  Argos  Software  and  is  a  modular  financial  and  management 
accounting  system  that  allows  the  users  to  select  their  needed  functionality.  The 
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sys-em’s  modules  that  support  the  DEH’s  needs  are  the  Sales  Order  Processing, 
Register  Sales,  Purchase  Order  Processing,  Inventory  Management,  Accounts 
Receivable,  Accounts  Payable,  General  Ledger,  and  Database  Query  modules. 
ABECAS  operates  on  all  IBM-compatible  PCs  and  is  capable  of  local  area 
networking. 

FOURGEN  Accounting  System 

The  FOURGEN  Accounting  System  is  a  modular  accounting  and  distribution 
system  that  satisfies  many  of  the  DEH’s  supply  management  system  requirements. 
For  instance,  USAEHSC  would  have  to  procure  the  Order  Entry,  Purchasing, 
Inventory  Control,  and  Utility  modules  so  that  the  system  can  satisfy  the  DEH’s 
needs.  FOURGEN  is  a  PC-based  system  written  in  INFORMIX,  a  4GL  language 
supported  by  a  relational  database  and  SQL. 

Macola  Accounting  and  Distribution  System 

The  Macola  Accounting  and  Distribution  System  (referred  as  MACOLA  in  the 
tables)  is  a  modular  inventory  control  and  accounting  system  developed  by  Macola, 
Incorporated.  The  modules  that  support  the  DEH’s  requirements  are  the  Customer 
Order,  Inventory  Management,  Purchase  Order,  Accounts  Receivable,  Accounts 
Payable,  Query,  and  System  Manager  modules.  The  Macola  System  is  a  PC-based 
system  that  operates  in  a  DOS  environment  and  can  be  configured  to  operate  in  a 
local  area  network. 

Information  Control  System  for  Manufacturers,  Distributors,  and  Retailers 

The  Information  Control  System  for  Manufacturers,  Distributors,  and  Retailers 
(referred  to  as  PIC  in  the  tables)  is  an  integrated  modular  system  developed  by  PIC 
Business  Systems,  Incorporated.  This  system  possesses  Order  Processing,  Inventory 
Management,  Purchase  Orders,  and  Systems  Utility  modules  that  will  support  the 
DEH’s  requirements.  The  system  is  written  in  a  proprietary  language  that  runs  on 
PC  platforms  and  can  be  configured  to  operate  in  a  network  environment. 

Great  Plains  Accounting  Series 

The  Great  Plains  Accounting  Series  System  (referred  to  as  PLAINS  in  the 
tables)  is  a  set  of  Accounting,  Inventory  Control,  and  Job-costing  modules  written  by 
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Great  Plains  Software,  Incorporated.  The  Plains  system  is  written  in  a  proprietary 
language  that  operates  in  a  DOS  or  UNIX  environment  on  PC  platforms. 

Financials  and  Distribution  System 

The  Financials  and  Distribution  System  (referred  to  as  TECSYS  in  the  tables) 
performs  order  entry,  inventory  management,  purchase  order,  and  financial 
functions.  The  system  was  developed  by  TecSys,  Incorporated,  and  was  written  in 
INFORMIX,  a  4GL  supported  by  a  relational  database  and  SQL,  to  run  in  a  UNIX 
environment. 

SYSTEMS  EVALUATION 

We  conducted  in-depth  interviews  at  working  sites,  when  possible,  to  determine 
how  well  each  of  the  remaining  10  Government  candidates  complied  with  the  specific 
technical  and  functional  requirements.  If  visits  to  actual  working  sites  were  not 
possible,  we  conducted  telephone  interviews  and  in-depth  research  into  the  system’s 
documentation.  At  the  same  time,  CERL  interviewed  private-sector  companies  to 
determine  how  well  the  6  private-sector  candidates  complied  with  the  proposed 
system  requirements.  Details  of  the  analysis  for  each  of  the  Government  candidate 
systems  are  included  in  Appendix  B.  Details  of  the  private-sector  system  scores  can 
be  found  in  the  CERL  report.  Facilities  Engineer  Supply  Management  System  Survey. 
The  results  for  the  10  Government  candidates,  the  6  private-sector  candidates,  and 
the  current  FESS  are  summarized  in  Table  2-1.  A  score  of  3.5  or  greater  is 
satisfactory  while  a  score  of  2.5  or  below  is  unacceptable. 

Since  upgrading  FESS  and/or  porting  it  to  new  hardware  are  also  alternative 
solutions,  we  examined  them  in  the  same  level  of  detail  as  the  other  candidate 
systems.  As  a  result  of  FESS’s  current  technical  deficiencies,  it  could  not  pass  the 
proposed  technical  requirements  imposed  on  the  next-generation  engineering  supply 
system.  However,  since  FESS  represents  the  status  quo,  we  retained  the  system  for 
cost  analysis. 

In  general,  we  found  that  the  three  mainframe  (MEDSTOC,  AMCISS,  and 
BOSS)  and  minicomputer  (CEMAS)-based  systems  complied  well  with  the  functional 
requirements.  However,  those  same  systems  satisfied  very  few  of  the  technical 
requirements  and  none  fully  satisfied  all  the  infinitely  weighted  criteria.  As  a  result, 
all  these  systems  failed  the  technical  evaluation  part  of  the  study  and  all  should  have 
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TABLE  2-1 


SYSTEM  COMPLIANCE  SCORES 


System 

Pass/Fai(a 

Technical 

Functional 

FESS 

Fail 

1  92 

3.68 

SBSS 

Fail 

1.40 

- 

CEMAS 

Fail 

2.21 

3.79 

MEDSTOC 

Fail 

1.83 

3  24 

WIS 

Pass 

3  87 

2.57 

AMCISS 

Fail 

1.98 

4  26 

APPMS 

Pass 

4.18 

2.92 

EPOS 

Pass 

4  25 

3.61 

CASTLE 

Pass 

447 

4.20 

BOSS 

Fail 

1  82 

4.19 

SARSS 

Pass 

3  68 

3  89 

ABECAS 

Pass 

4.21 

4.56 

FOURGEN 

Pass 

4.34 

4.28 

MACOLA 

Pass 

4.30 

4.40 

PIC 

Pass 

4.41 

4.20 

PLAINS 

Pass 

4,20 

4.52 

TECSYS 

Pass 

4  67 

4.57 

Fail  indicates  the  system  failed  to  pass  one.  several,  or  all  the  infinitely  weighted 
criteria 


been  dropped  from  further  consideration  because  the  costs  to  make  them  comply  with 
the  technical  constraints  would  be  prohibitive.  However,  both  AMCISS  and  BOSS 
possessed  such  high  functional  scores,  they  were  retained  for  the  sake  of  comparison. 

Both  the  public-  and  private-sector  PC-based  systems  that  we  examined  and  the 
SARSS  presented  an  entirely  different  picture.  For  the  most  part,  they  had  average- 
to-excellent  compliance  with  the  functional  requirements  but  very-good-to-excellent 
compliance  with  the  technical  requirements.  As  would  be  expected,  all  these  systems 
performed  most  of  the  required  inventory  control  and  supply  management  functions 
and  the  deficiencies  that  existed  were  the  result  of  unique  Government  and  Army 
operations.  For  example,  none  of  the  private-sector  systems  interfaced  with  the 
required  Government  systems,  generated  the  required  documents/forms,  performed 
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the  required  level  of  job  cost  control,  or  ordered  materials  according  to  military 
standard  requisitioning  and  issue  procedures  (MILSTRIP).  However,  the  deficiencies 
in  all  of  these  systems  are  such  that  some  reprogramming  could  enable  them  to  fully 
satisfy  the  objectives  of  the  proposed  system  requirements.  Users  of  the  PC-based 
systems  almost  unanimously  agreed  that  greater  flexibility  and  better  control  of 
system  changes  and  costs  were  major  advantages  of  those  systems. 

In  part,  we  used  the  technical  and  functional  compliance  of  each  candidate 
system  to  eliminate  potential  candidate  systems  and  to  reduce  them  to  a  manageable 
number.  Of  the  10  candidate  Government  systems  that  were  analyzed  for  technical 
and  functional  compliance  with  the  established  requirements,  only  7  were  considered 
strong  contenders  and  subjected  to  the  cost  analysis.  All  6  private-sector  systems 
were  carried  forward  to  the  cost  analysis  portion  of  this  study. 
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CHAPTERS 


COST  ANALYSIS 


METHODOLOGY 

The  life-cycle  costs  of  any  information  system  can  be  divided  into  the  following 
components:  requirements  analysis,  specification,  design,  coding,  testing, 
implementation  (i.e.,  integration,  fielding,  and  training),  and  maintenance  (i.e., 
normal  operations,  corrections,  and  upgrades).  Since  the  requirements  analysis  and 
specification  phases  were  already  complete,  we  needed  to  estimate  only  the  costs  to 
modify  (to  meet  the  technical  and  functional  requirements  of  the  DEHs),  implement 
the  modified  system  at  all  DEH  sites,  and  maintain  each  system  for  a  period  of 
10  years.  Costs  were  estimated  in  terms  of  the  number  of  man-days  of  effort. 
Table  3-1  shows  a  summary  of  costs  for  the  13  candidate  systems,  the  cost  to  develop  a 
new  custom  system,  the  cost  to  port  FESS  to  a  PC  platform,  and  the  cost  to  continue 
using  FESS  with  proposed  upgrades. 

Many  factors  were  necessarily  considered  in  making  estimates  for  each  system. 
The  size  of  the  system  affects  life-cycle  costs,  since  larger  systems  are  more  difficult  to 
develop  and  maintain.  The  number  of  lines  of  program  code,  the  number  of  programs 
or  modules,  and  the  size  and  number  of  data  files  used  by  the  system  were  all 
considered.  In  addition,  we  assumed  that  systems  written  in  3GL,  such  as  COBOL, 
take  more  time  to  develop  and  maintain  than  systems  written  in  4GL,  such  as 
dBASE  HI.  We  also  assumed  that  mainframe  systems  require  even  more  effort  than 
PC-based  systems  because  of  the  increased  complexity  of  operating  systems  and 
interfaces. 

Developing  life-cycle  cost  estimates  for  any  automated  system  is  not  an  exact 
science;  however,  our  life-cycle,  man-hours-of-effort  estimates  show  relative 
differences  between  candidate  systems  and  provide  a  sound  basis  on  which  to  make 
decisions  among  the  various  alternatives. 
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TABLE  3-1 


ESTIMATED  SYSTEM  LIFE-CYCLE  COSTS 


Candidate 

system 

Modification 

(man-days) 

Implementation 

(man-days) 

Operation  and 
maintenance 
(man-days) 

Total 

(man-days) 

APPMS 

457 

5,060 

7,200 

12,717 

AMCISS 

1,112 

10,060 

868,448 

879,620 

BOSS 

1,265 

10,060 

869,060 

880,385 

WiS 

457 

5,060 

7,200 

12,717 

CASTLE 

145 

5,060 

7,200 

12,405 

EPOS 

556 

5,060 

10,800 

16,416 

SARSS 

715 

5,060 

14,400 

20,175 

New  custom 
system 

3,600 

5,060 

8,600 

17,260 

FESS-PC 

4,246 

5,060 

14,400 

23,706 

FESS-mini 

1,144 

2,530 

80,000 

83,674 

ABECAS 

68 

5,060 

7,200 

12,328 

FOURGEN 

122 

5,060 

7,200 

12,382 

MACOLA 

144 

5,060 

7,200 

12,404 

PIC 

155 

5,060 

7,200 

12,415 

PLAINS 

84 

5,060 

7,200 

12,344 

TECSYS 

170 

5,060 

7,200 

12,430 

MODIFICATION  COSTS 

Each  candidate  system  was  scored  by  how  well  it  complied  with  the  established 
system  requirements.  Those  scores  were  then  used  to  estimate  the  number  of 
man-days  necessary  to  modify  each  system  to  comply  totally  with  all  of  the  functional 
and  technical  requirements.  For  example,  if  a  candidate  received  a  rating  of  two  for 
any  particular  criterion,  the  number  of  man-days  of  programming  required  to  raise 
the  system’s  rating  to  a  five  (total  compliance)  was  estimated  for  each  noncompliant 
criterion. 

The  following  components  were  considered  in  our  modification  estimates: 
analysis  of  the  particular  system  requirement,  design  of  the  solution,  and  coding  and 
testing  of  the  solution.  Since  all  DEHs  have  common  needs,  we  assumed  that  all 
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modifications  would  be  centrally  managed.  We  assumed  that  modifications  to  PC 
systems  made  after  implementation  fall  under  maintenance  and  that  database 
conversions  from  FESS  to  the  new  system  are  considered  as  implementation  costs. 

Six  of  the  public-sector  candidate  systems  (APPMS,  WIS,  CASTLE,  EPOS, 
FESS-PC,  and  new  custom  system)  shown  in  Table  3-1  are  PC-based  systems.  In 
general,  the  costs  to  modify  PC-based  systems  are  lower  than  those  for  mainframe 
systems.  The  two  mainframe  systems  considered  (AMCISS  and  BOSS)  are  both 
25  years  old,  are  written  in  COBOL  (1974  ANSI  standard),  contain  hundreds  of 
thousands  of  lines  of  code,  contain  dozens  of  separate  programs  and  data  files,  and  do 
not  use  relational  database  structures.  These  kinds  of  mainframe  systems  are  much 
more  difficult  to  modify  than  PC-based  systems.  The  cost  in  time  required  to  prepare 
and  justify  system  change  requests  for  approval  was  also  added  into  the  estimates. 
SARSS  is  a  mini-computer-based  system,  written  in  a  combination  of  COBOL  and 
INFORMIX  (a  4GL  and  relational  DBMS).  Its  costs  will  be  between  those  of  the  PC 
and  the  mainframe  systems. 

Three  of  the  public-sector  candidate  systems  considered  in  Table  3-1  (APPMS, 
WIS,  CASTLE,  and  perhaps  the  new  custom  system)  are  written  in  a  4GL.  In 
general,  source  code  developed  in  a  4GL  requires  less  development  time  than  source 
code  developed  in  a  3GL  because  higher  level  languages  make  use  of  prewritten 
subroutines,  handle  system  interfaces  automatically,  have  menu-driven  commands 
or  command-syntax  that  looks  much  like  English  sentences,  and  have  features  that 
allow  them  to  be  used  as  relatively  fast  application  generators.  Also,  the  fact  that 
4GLs  require  fewer  lines  of  code  to  program  a  particular  function  than  3GLs  is  an 
obvious  advantage. 

The  modification  effort  presented  in  Table  3-1  considers  the  programming 
complexity  each  technical  and  functional  criterion  requires.  For  example,  systems 
that  need  programming  to  automate  an  item  pick  documents  feature  are  relatively 
complicated  because,  among  other  things,  special-purpose  output  forms  must  be 
designed  and  tested.  Adding  replenishment  capability  is  simple  by  comparison, 
because  it  only  requires  a  short  programming  module  that  uses  relatively  few,  well- 
known  formulas.  However,  programming  is  not  a  sequential  process  and  economies 
of  scale  will  definitely  be  realized.  For  example,  the  functional  category  of 
pickingUssue  requirements  consists  of  four  subfunctions  —  create  pick  documents, 
automatically  coordinate  material,  automatically  issue  return  slips,  and  determine 
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picking  criteria  —  that  will  probably  use  many  of  the  same  parameters  and 
algorithms,  with  only  slight  variations.  Therefore,  fewer  programming  hours  will  be 
required  to  make  the  modifications  as  a  group  than  to  make  them  individually.  By 
comparison,  the  canned  queries  and  ease  of  use/self-help  suhfunctions  do  not  offer 
economies  of  scale.  In  several  cases,  because  of  economies  of  scale,  we  estimated  the 
required  man-days  for  an  entire  technical  or  functional  criteria  set,  and  not  by 
individual  subfunction  criteria. 

The  technical  criteiia  with  "infinite”  weights  do  not  have  man-days  of 
modification  associated  with  them;  they  are  rated  either  "pass”  or  "fail”  because  of 
the  criticality  of  those  criteria.  Even  though  the  mainframe  systems  "failed”  the 
relational  database  and  distributed  configuration  criteria,  we  retained  them  for  life- 
cycle-cost  comparison  purposes.  Also,  even  though  the  mainframe  systems  are  not 
platform  independent,  we  did  not  include  a  modification  cost  to  port  them  to  a  PC. 
Such  modification  costs  would  be  pointless  and  prohibitively  expensive  compared  to 
building  a  new  system  from  scratch.  We  assumed  that  they  would  continue  to 
operate  on  their  current  mainframe  platforms. 

We  summarize  the  total  estimated  man-days  of  modification  effort  for  each 
system  in  Column  2  of  Table  3-1.  Appendix  C  displays  our  detailed  estimates  of 
modification  time  required  by  the  technical  and  functional  criteria  for  each  public- 
sector  candidate  system.  The  detailed  estimates  for  the  private-sector  candidates  can 
be  found  in  CERL’s  final  report.  Facilities  Engineer  Supply  Management  System 
Survey. 

Modification  estimates  for  the  six  private-sector  systems  (ABECAS, 
FOURGEN,  MACOLA,  PIC,  PLAINS,  and  TECSYS)  were  provided  by  CERL.  Since 
each  of  the  candidate  systems  is  proprietary,  the  systems’  vendors  were  given  the  list 
of  system  deficiencies  and  asked  to  estimate  the  level  of  effort  (in  man-days)  required 
to  program  the  systems  to  satisfy  the  proposed  DEH  system  requirements.  The 
vendors  responded  with  varying  levels  of  detail,  but  a’l  the  estimates  were  of  a 
similar  magnitude. 

We  found  that  PC-based  systems  have  lower  total  modification  costs  than  the 
mainframe  systems  even  for  APPMS  and  WIS,  which  need  more  functional 
modifications  than  the  mainframe  systems.  CASTLE  and  the  six  private-sector 
systems  require  the  least  amount  of  modification  effort  because  they  have  the  highest 
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technical/functional  scores,  they  are  PC-based,  and  they  are  written  in  a  4GL. 
CASTLE  was  developed  in  90  man-days  (excluding  user-client  effort),  and  the  alpha 
and  beta  tests  were  completed  within  1  year  with  a  relatively  minor  number  of  man- 
days  for  corrections/upgrades.  The  EPOS  system  will  require  more  programming 
effort  than  WIS  and  APPMS  because  it  is  written  in  a  3GL;  however,  EPOS  is  easier 
to  modify  than  the  mainframe  systems.  Porting  FESS  to  a  networked  PC  system  will 
be  the  most  difficult  task  because  interfaces  to  the  operating  systems  must  be 
changed  and  two  different  coding  languages  must  be  converted,  in  addition  to 
upgrading  its  functionality.  A  new  custom  system  will  be  the  next  most  costly  to 
develop  because  it  must  be  developed  from  scratch.  Our  estimates  for  developing  a 
new  custom  PC  system  assume  that  it  would  be  programmed  in  a  4GL  and  include 
the  effort  of  user-clients  for  design  and  testing,  a  sometimes  hidden  design  cost 
already  borne  by  existing  candidate  systems.  The  estimates  for  converting  SARSS  to 
a  DEH  supply  system  are  higher  than  for  the  PC  systems,  since  both  COBOL  and 
INFORMIX  modules  would  have  to  be  modified. 

IMPLEMENTATION  COSTS 

The  following  activities  were  considered  in  our  implementation  estimates: 
centralized  creation/modification  of  system  documentation  (including  users  guides), 
local  database  conversion  from  FESS  to  the  new  custom  system,  local  system 
installation,  local  training,  and  centralized  planning  and  follow-up  for  all 
implementation  activities.  We  assumed  100  separate  sites  in  our  estimates.  For  the 
PC-  and  mini-based  systems,  local  installation  (including  follow-up  support)  would 
require  about  10  man-days  of  effort  and  database  conversion  would  require  about 
40  man-days  of  effort.  For  the  mainframe  systems,  local  installation  would  require 
about  20  man-days  of  effort  and  database  conversion  would  require  another  80  man- 
days  of  effort.  Those  estimates  came  to  about  5,000  man-days  of  effort  for  PC  and 
10,000  man-days  for  mainframe  systems  implementation.  For  all  candidate  systems, 
an  additional  60  man-days  of  effort  was  added  for  the  centralized  documentation 
activities,  yielding  an  estimate  of  5,060  and  10,060  man-days  of  total  implementation 
costs  for  PC  and  mainframe  systems,  respectively.  Implementation  of  an  upgraded 
FESS  on  the  existing  platform  was  assumed  to  be  half  the  cost  of  implementing  a  new 
PC  system.  These  cost  estimates  are  shown  in  Column  3  ofTable  3-1. 
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OPERATION  AND  MAINTENANCE  COSTS 


After  new  systems  have  been  implemented,  maintenance  costs  begin,  and  they 
continue  through  the  operational  life  of  the  system.  The  operational  life  of  any  new 
DEH  system  is  determined  by  how  well  the  system  continues  to  meet  such  DEH  needs 
as  hardware  and  software  reliability,  changes  in  hardware  and  software  technology, 
changes  to  DEH  supply  management  requirements,  and  system  operator  and 
maintenance  costs  among  other  needs.  It  is  difficult  to  select  an  exact  time  frame  for 
any  new  system’s  life  cycle:  FESS  is  over  10  years  old  and  BOSS  and  AMCISS  have 
lasted  25  years  already.  However,  for  purposes  of  this  cost  analysis,  we  selected  a 
10-year  life  cycle. 

The  maintenance  phase  estimates  considered  several  activities:  corrections  to 
software,  upgrades  to  new  releases  of  operating  and  application-base  software  (e.g., 
dBASE,  C,  COBOL),  hardware  expansions  and  upgrades,  modification  of  application 
software  to  include  new  technical  or  functional  capabilities  (e.g.,  multimedia), 
changes  to  system  interfaces,  documentation  updates,  and  time-connect  charges  and 
long-distance  telephone  costs  (if  any)  for  mainframe  systems.  Our  estimates  assume 
that  the  initial  system  modifications,  documentation,  and  maintenance  would  be 
performed  centrally.  Although  local  maintenance  is  an  option,  not  all  sites  would 
have  the  technical  capability  necessary  to  make  programming  and  database  changes. 
Furthermore,  consistency  of  the  technical  and  functional  quality  of  the  installations 
would  be  lost.  Therefore,  the  estimates  measure  implementation  of  a  compiled 
version  of  the  software  at  each  site  to  preclude  local  system  changes.  Subsequently, 
USAEHSC  would  maintain  the  system  centrally  —  similar  to  its  current 
responsibility  with  FESS  —  except  that  maintaining  a  4GL  system  would  only 
require  a  fraction  of  the  costs  of  maintaining  FESS. 

The  estimated  operation  and  maintenance  costs  for  each  candidate  system  are 
shown  in  Column  4  of  Table  3-1.  We  assumed  an  average  of  10  terminals  per 
installation,  an  average  of  $200/month  connection  charges  and  long-distance 
telephone  costs  per  terminal,  and  100  installations. 

The  costs  for  the  mainframe  systems  are  much  greater  than  PC-based  systems 
because  of  time-connection  charges  and  long-distance  telephone  costs.  Annual 
system-wide  connection  charges  alone  cost  $2.4  million.  If  we  assume  an  average 
man-year  cost  of  $50,000  fully  loaded,  this  yields  48  man-years  or  86,400  "equivalent 


man-days”  of  cost.  Over  a  10-year  life-cycle,  this  would  result  in  an  equivalent 
864,000  man-days  of  effort. 

The  other  maintenance  costs  for  mainframe  and  PC  systems  were  derived  using 
a  multiplicative  factor.  For  a  traditional  mainframe,  3GL  systems  studies  have 
shown  that  maintenance  costs  normally  account  for  70  to  80  percent  of  a  system’s 
total  life-cycle  costs. l  Since  BOSS  and  AMCISS  are  more  than  20  years  old,  have  not 
been  converted  to  the  latest  ANSI  standard  COBOL,  use  custom-written  and 
nonrelational  databases,  and  are  not  SQL  compatible,  we  used  the  80  percent  figure 
for  a  10-year  life  cycle.  Thus  maintenance  costs  were  estimated  at  four  times  the 
modification  costs.  Similar  studies  have  not  yet  been  widely  published  for  PC 
systems;  however,  we  assumed  they  would  be  cheaper  for  all  of  the  reasons  discussed 
above.  We  therefore  assumed  factors  of  two  and  three  for  PC  systems  written  in  4GL 
and  3GL,  respectively. 

For  PC-based  systems  owned  by  USAEHSC,  the  multiplicative  factor  should  be 
applied  to  the  full  development  cost  of  those  systems.  Therefore,  given  an  estimated 
3,600  man-days  to  develop  a  new  custom  PC  system  from  scratch  in  a  4GL,  the 
operation  and  maintenance  effort  of  the  PC-4GL  systems  over  10  years  would  be 
approximately  7,200  man-days.  The  effort  required  for  the  EPOS  (3GL  system) 
would  be  about  10,800  man-days.  The  maintenance  effort  shown  for  FESS  is  the 
current  contractual  maintenance  costs  converted  to  man-days. 

LIFE-CYCLE  COSTS 

The  total  life-cycle  costs  for  10  years  are  shown  in  the  last  column  of  Table  3-1. 
The  estimates  show  that  primarily  because  of  lower  maintenance  costs,  any  PC 
system  would  require  much  less  effort  than  the  mainframe  systems  and  that  4GL 
systems  require  less  effort  than  the  3GL  systems.  In  addition,  the  life-cycle  costs  of 
keeping  FESS  on  its  existing  platform  but  upgrading  its  functions  were  also  much 
higher  than  the  PC  systems  because  it  is  written  in  VISION  and  COBOL  and  will 
continue  to  be  difficult  to  maintain  over  the  next  10  years.  Porting  FESS  to  a  new 
hardware  platform  resulted  in  lower  maintenance  effort  although  the  initial 
modification  costs  were  the  highest. 


'Melior,  Page  Jones,  The  Practical  Guide  to  Structured  Systems  Design,  Yourdon  Press, 
Englewood  Cliffs,  N  J.  2nd  edition,  1989.  p.  26. 
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Because  the  private-sector  systems  are  not  already  owned  by  the  Government, 
additional  costs  will  be  associated  with  procuring  one.  More  time  will  be  needed  to 
generate  contract  specifications,  develop  a  request  for  proposal,  and  proceed  through 
the  Government  acquisition  process.  In  addition,  costs  will  be  associated  with 
licensing  and  acquiring  the  vendor’s  source  code.  CERL  investigated  those  additional 
costs  and  found  that  private-sector  companies  would  be  willing  to  provide  source  code 
and  licensing  for  between  $1,000  to  $6,000  per  site  ($100,000  to  $600,000  total).  Each 
vendor  expressed  interest  in  responding  to  a  request  for  proposals  and  was  willing  to 
sell  the  source  code.  It  is  likely  that  these  quoted  prices  could  be  negotiated  for  less 
during  a  competitive  procurement. 

The  total  life-cycle  costs  for  a  new  custom  system,  private-sector  systems,  and 
the  4GL  public-sector  systems  appear  to  be  relatively  close.  However,  Table  3-1  does 
not  reflect  the  impact  of  timing  (opportunity  cost).  This  is  potentially  a  large  cost  for 
those  systems  that  could  take  up  to  a  year  to  procure  or  to  modify/develop,  test,  and 
implement.  During  that  time,  both  the  current  FESS  hardware  and  software  would 
have  to  be  maintained  at  a  rate  of  $1.5  million  for  hardware  and  $0.5  million  for 
software  for  another  year  or  more.  That  cost  can  be  avoided  since  an  existing  public- 
sector  PC  system  can  be  modified  and  implemented  quickly. 
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CHAPTER 4 


CONCLUSIONS  AND  RECOMMENDATIONS 


CONCLUSIONS 

In  today’s  highly  dynamic  automated  systems  environment,  no  computer 
information  system  is  designed  to  last  indefinitely.  New  technological  advances  are 
made  so  quickly  that  existing  systems  can  become  obsolete  and  increasingly  difficult 
to  maintain  (compared  to  newer  systems)  within  a  matter  of  years.  While  the  FESS 
continues  to  be  a  useful  and  popular  automated  system,  it  is  more  than  10  years  old 
and  through  normal  system  evolution  has  entered  the  last  stages  of  its  life  cycle.  The 
FESS  software  alone  costs  more  than  $0.5  million  a  year  to  maintain,  and  its 
hardware  platform,  the  Motorola  IV  Phase  minicomputer,  is  also  dated  and  costs 
more  than  $1.8  million  a  year;  those  costs  will  likely  increase  in  the  future.  We 
believe  the  Army  can  no  longer  afford  to  maintain  FESS  in  its  current  form  and 
should  either  replace  or  upgrade  it. 

Using  FESS’s  current  functionality  and  proposed  improvements  to  the  system 
as  the  baseline,  the  USAEHSC  has  already  decided  how  the  next-generation 
engineering  supply  system  should  function  and  what  technical  constraints  will 
support  those  requirements.  Any  of  the  alternatives  that  upgrade  the  current  FESS 
software  or  keep  the  Motorola  FV  Phase  hardware  intact  impose  unnecessary  costs  on 
the  Army.  Although  FESS  itself  is  the  basis  for  the  proposed  system,  it  does  not  fully 
satisfy  all  the  proposed  functional  requirements  nor  the  proposed  technical  system 
specifications;  to  make  it  meet  the  criteria,  some  cost-prohibitive  modifications  would 
be  required.  Our  analysis  demonstrates  that,  in  its  current  form,  modifying  FESS  in 
any  fashion  would  not  be  cost-effective. 

For  example,  since  FESS  is  programmed  in  VISION  and  nonstandard  COBOL, 
programming  new  functional  upgrades  is  more  difficult  and  therefore  more  expensive 
than  if  it  were  programmed  in  a  current,  commercially  available  4GL.  Furthermore, 
FESS  is  not  supported  by  SQL  which  makes  communications  to  other  DEH,  Army, 
and  DoD  systems  more  difficult  and  more  expensive.  Automated  systems  supported 
by  SQL  greatly  simplify  the  effort  required  to  program  new  interfaces,  which  is 
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particularly  important  considering  the  volatile  nature  of  those  other  systems  that 
FESS  must  communicate  with. 

For  similar  reasons,  converting  the  FESS  software  to  run  on  other  hardware 
platforms  or  porting  FESS  to  a  new  PC  platform  is  also  very  expensive,  if  at  all 
possible,  given  that  there  has  been  little  success  converting  2GL  to  4GL.  Even  when 
same-generation  languages  are  converted,  such  conversions  often  result  in  numerous 
program  error®  which  may  require  more  effort  to  debug  than  would  otherwise  be 
necessary  if  an  entirely  new  system  were  programmed  in  a  modern  language. 
Furthermore,  simply  upgrading  the  current  version  of  FESS  would  leave  its  software 
and  hardware  platform  in  place,  would  not  support  the  DEH’s  move  toward  a  more 
flexible  and  open  systems  architecture  environment  (i.e.,  the  IFS-M  platform),  and 
would  continue  to  cost  the  Army  at  least  $2.3  million  per  year  to  maintain. 

Since  FESS  is  not  a  cost-effective  starting  point  (in  terms  of  technology)  from 
which  to  base  the  future  supply  management  system,  all  existing  hardware  and 
software  must  be  replaced.  Several  automated  supply  management  systems  from 
both  the  private  and  public  sector  already  exist  and  comply  with  enough  functional 
and  technical  requirements  to  make  them  cost-effective  replacements  even  with 
modification  expenses  considered.  Adapting  an  existing  system  will  preclude  the 
need  for  the  system  design,  programming,  and  alpha  and  beta  testing  that  would  be 
required  for  a  totally  new  system  and  would  set  back  system  implementation  by 
about  1  year  —  time  that  could  be  used  to  implement  an  existing  system.  Although 
programming  a  completely  new  system  that  meets  all  system  requirements  is  not  the 
most  cost-effective  alternative  from  a  life-cycle  costs  basis,  USAEHSC  should 
consider  this  alternative  as  a  second  choice  if  they  find  that  acquiring  an  existing 
system  is  either  administratively  impossible  or  impractical. 

Given  the  system  configurations  of  the  current  hardware  (Motorola  IV  Phase) 
and  software  (FESS)  and  the  expected  role  automation  will  play  in  DEH  supply 
management  systems,  there  is  no  reason  to  preclude  PC-based  systems  from  such 
consideration.  The  evidence  from  the  life-cycle  costs  analysis  indicates  that  PC-based 
systems  written  in  a  4GL,  supported  by  a  relational-type  database  and  SQL,  and 
configured  to  operate  in  a  network  environment  will  contribute  to  the  DEH’s  move 
toward  an  open  system’s  architecture  and  will  require  much  less  effort  to  maintain. 
Also,  processing  speed  and  resident  memory  of  PC-based  file-server  configurations 
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can  easily  satisfy  both  technical  and  functional  requirements  of  the  new  system. 
Fixed  storage  in  today’s  market  is  relatively  affordable  and  can  be  configured  to 
satisfy  the  600  Mbytes  needed  by  the  current  systems  although  the  hardware 
platform  supporting  the  new  supply  management  system  will  probably  need  less 
fixed  storage.  In  addition,  the  PC  systems  are  more  flexible  and  expandable  and  fit  in 
with  the  DEH  information  system  architecture  strategy.  Also,  given  the  uncertainty 
of  the  future  of  other  Army  and  DoD  systems  that  interface  with  the  supply 
management  system,  the  fact  that  the  existing  PC-system  candidates  are  all 
programmed  in  4GLs  with  relational-type  databases  and  SQL  greatly  reduces  the 
risk  and  costs  associated  with  these  uncertainties. 

Further  examination  of  the  life-cycle  costs  shows  that  the  greatest  savings  were 
realized  during  the  implementation  and  maintenance  phases  and  that  the  system’s 
hardware  platform  is  far  more  critical  than  the  software’s  functionality.!  This 
suggests  that  whenever  a  system’s  requirement  can  be  handled  by  a  PC  application, 
PCs  should  be  used.  Since  DEH  supply  operations  do  not  require  the  power  of  a 
mainframe  computer  to  run  an  automated  supply  management  system,  DEHs  should 
avoid  the  use  of  mainframes. 

In  addition  to  the  life-cycle  costs  discussed  above,  selecting  a  supply 
management  system  that  is  built  around  a  commercially  available,  4GL  database 
software  package  offers  other  advantages.  First,  the  system  can  undergo  periodic 
database  system  improvements  as  they  become  commercially  available.  This  ensures 
a  minimum  cost  for  implementing  technological  advances.  Second,  since  the  future  of 
other  Army  and  DoD  information  systems  is  not  clear,  it  is  important  to  remain 
flexible  so  that  DEH  systems  can  react  to  expected  and  unexpected  changes. 

Since  modifying  one  of  the  PC-based  candidates  is  the  least-cost  alternative, 
assuming  that  acquiring  the  software  is  possible  and  practical,  we  must  determine 
which  of  the  public-  or  private-sector  systems  will  be  the  most  cost-effective  choice. 
Any  of  the  candidates  that  were  evaluated  can  be  made  to  satisfy  the  proposed  system 
requirements.  Although  the  analysis  showed  that  the  effort  required  to  modify  one  of 
the  private-sector  systems  was  actually  less,  some  additional  costs  are  associated 


’An  often  used  rule  of  thumb  estimates  that  operation  and  maintenance  costs  are  three  to  five 
times  as  much  as  development  costs 
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with  procuring  and  licensing  any  of  the  private-sector  candidates  that  would  not  be 
required  of  the  systems  already  owned  by  the  Government. 

Acquiring  an  automated  system  through  a  competitive  procurement  will  result 
in  additional  costs  and  time.  Since  none  of  the  private-sector  systems  can  be 
purchased  "off  the  shelf,”  USAEHSC  would  have  to  plan  and  develop  a  request  for 
proposals  (RFP)  that  clearly  defines  the  system  requirements  as  well  as  the 
Government’s  ownership  rights.  It  is  likely  that  the  acquisition  process  alone  would 
take  as  much  as  one  additional  year.  Assuming  that  the  costs  to  eventually  modify 
the  private-sector  system  were  less  than  or  equal  to  the  costs  to  modify  one  of  the 
Government-owned  systems,  we  believe  that  the  additional  costs  and  time  for  a 
competitive  acquisition  greatly  exceed  any  additional  costs  needed  to  modify  one  of 
the  systems  already  owned  and  maintained  by  the  Army  —  for  example,  CASTLE. 
Also,  such  acquisitions  increase  the  risk  associated  with  future  maintenance  costs 
and  control  over  likely  upgrades  or  changes.  All  together,  the  additional  costs  and 
risks  associated  with  acquiring  a  private-sector  system  outweigh  the  slight  benefit  in 
functional  performance. 

RECOMMENDATIONS 

We  recommend  that  USAEHSC  adapt  an  existing  Government-owned  PC- 
based  supply  management  system  such  as  CASTLE  or,  if  acquiring  the  system  proves 
impractical,  develop  a  comparable  system  to  totally  comply  with  the  proposed 
detailed  system  requirements.  The  candidate  system  should  be  totally  compatible 
with  IFS-M  architecture  (e.g.,  UNIX/DOS  compatible),  be  supported  by  a  relational- 
type  database,  and  be  written  in  a  4GL.  Since  CASTLE  is  built  around  a  commercial, 
4GL  database  software  package,  it  can  take  advantage  of  periodic  technological 
updates  as  they  become  commercially  available,  which  ensures  minimum  cost  for 
implementing  these  technological  advances. 

To  guarantee  that  the  DEH  users  will  get  a  system  that  totally  satisfies  their 
supply  management  needs,  we  further  recommend  that  USAEHSC  reevaluate  the 
detailed  requirements  phase  of  the  system  analysis  process.  That  evaluation  will 
ensure  that  all  system  requirements  have  been  thoroughly  identified,  properly 
communicated  to  the  system  analysts,  and  well  documented.  A  well-documented 
analysis  minimizes  the  costs  associated  with  the  system  design  and  programming 
phases  and  reduces  future  maintenance  costs. 
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SYSTEM  REQUIREMENTS 


As  the  result  of  detailed  requirements  analysis  conducted  by  a  team  of  Army 
installation-level  users,  functional  experts,  and  technical  professionals,  a  set  of 
detailed  requirements  for  the  next-generation  engineering  supply  management 
system  was  developed.  This  appendix  provides  a  brief  description  of  each  of  the 
functional  and  technical  criteria  used  to  evaluate  the  candidate  systems. 

To  ensure  that  the  proposed  supply  management  system  would  meet  the  overall 
future  system  needs  of  the  Directorates  or  Division  of  Engineering  and  Housing 
(DEHs),  several  of  the  technical  requirements  were  given  infinite  weights.  Infinitely 
weighted  criteria  were  considered  so  important  to  the  proposed  supply  system 
configuration  that  any  candidate  system  that  failed  to  comply  was  dropped  from 
further  consideration.  This  ensures  that  all  systems  considered  for  replacing  the 
Facility  Engineering  Supply  System  (FESS)  would  meet  four  important  needs. 

First,  the  new  system  must  be  on-line  and  interactive  with  the  users,  which 
reduces  the  time  users  would  otherwise  have  to  wait  in  a  batch  processing 
environment.  In  addition,  this  on-line  interface  should  be  user  friendly  and  well 
supported  by  system  help  screens. 

Second,  the  system  must  support  a  distributed  configuration  so  that  as  many  as 
30  users  can  log  onto  it  simultaneously.  The  DEH  supply  environment  is  too  dynamic 
to  expect  personnel  to  share  terminals,  and  storage  warehouses  are  too  vast  to  expect 
personnel  to  walk  to  a  centralized  computing  area  to  make  transaction 
inputs/outputs. 

Third,  the  supply  system  must  be  capable  of  interfacing  with  the  DEH’s  real 
property  maintenance  activity  (RPMA)  work  control  platform.  Integrated  Facilities 
System-Mini/Micro  (IFS-M).  It  is  critical  that  the  two  systems  share  information  so 
that  planners/estimators  have  access  to  the  most  current  inventories  and  associated 
costs,  that  schedulers  have  access  to  current  in-stock  and  replenishment  status,  that 
customer  service  representatives  can  accurately  report  the  status  of  inventories  and 


job  execution  to  DEH  clients,  and  that  resource  management  personnel  can 
accurately  reflect  job  costs  which  include  the  materials. 

Fourth,  the  supply  system  must  be  supported  by  a  relational-type  database  and 
standard  query  language  (SQL).  This  ensures  that  a  minimal  effort  will  be  needed  to 
generate  database  queries;  create  management  reports;  and  program  interfaces  to 
other  DEH,  Army,  and  DoD  systems.  These  criteria  are  critical  considering  that  the 
remaining  parts  of  the  Army,  DoD,  Government,  and  private  industry  are  moving 
toward  relational-type  databases  and  that  SQL  ensures  simplified  communication 
between  different  systems. 

TECHNICAL  CRITERIA 

Availability 

Although  "availability”  was  not  weighted  during  the  analytic  hierarchical 
process  (AHP)  session,  the  IFS-M  configuration  control  board  has  determined  that 
the  engineering  supply  management  module  should  be  in  place  by  the  beginning  of 
1992.  That  means  candidate  systems  must  be  available  (plus  development  time)  by 
that  date.  Resource  constraints  may  make  this  impossible,  but  for  purposes  of 
analysis  we  did  not  examine  supply  management  systems  that  were  only  in  the 
planning  phase.  Candidate  systems  had  to  be  programmed,  fully  tested,  and 
running. 

On-Line  Capability 

The  proposed  supply  management  system  must  be  on-line  and  interactive. 
Batch  processing  is  not  acceptable.  Real-time  processing  is  preferred  but  not 
mandatory. 

Required  Database  Management  System 

This  system  is  the  heart  of  the  proposed  supply  management  system.  The 
future  system  (and  therefore  the  candidates)  must  be  supported  by  a  relational-type 
database  together  with  SQL  or  programmed  in  a  language  that  will  soon  be  converted 
to  be  compatible  with  SQL.  Also,  the  candidates  must  already  have  file  maintenance 
programming  in  place.  These  criteria  are  considered  essential  and  candidates  that  do 
not  comply  with  these  requirements  will  not  be  considered  further.  The  requirement 


for  a  technically  supportable  database  management  system  must  also  include  the 
following  five  components. 

Relational  Database/SQL 

Data  must  be  represented  by  a  relational-type  database  so  that  the  data  can 
conform  to  the  IFS-M  architecture  and  ensure  an  open  systems  architecture  that  is 
totally  flexible.  By  "relational”  we  mean  a  series  of  two-way  tables  that  can  be  easily 
linked  together  in  an  infinite  variety  of  data  relationships,  allowing  maximum 
information  flexibility  and  accessibility.  SQL  is  the  accepted  national  standard  (and 
growing  Army  standard)  for  accessing  data  in  a  relational  database,  ’’  ’  'ch  once 
written,  can  be  used  on  any  hardware  and  any  relational  database  software.  Systems 
that  do  not  comply  with  this  requirement  or  are  not  planned  for  this  future 
enhancement  will  not  be  considered  further. 

System  Files  Maintenance 

The  system  must  include  utilities  to  file,  maintain,  store,  retrieve,  and  optimize 
disk  space.  The  system  must  also  be  capable  of  making  system  back-ups  and 
restoring  information. 

Ease  ofUselSelf-Help  Capability 

The  proposed  system  should  be  user  friendly  and  should  be  supported  by 
effective  on-line  help  screens  and  windows.  Help  menus  outside  the  running  program 
will  be  considered  noncompliant. 

Canned  Queries 

Preprogrammed  database  queries  that  satisfy  many  of  the  supply  management 
needs  should  be  available. 

Documentation 

Candidate  systems  must  be  supported  by  usable  documentation  such  as 
existing  data  dictionaries  or  encyclopedias,  dataflow  diagrams,  entity-relationship 
diagrams,  flow  charts,  and  users  manuals.  Fully  documented  systems  will  ensure 
that  system  programmers  understand  the  detailed  requirements. 


System  Independence 

The  proposed  system  must  be  able  to  operate  independently  (stand  alone)  from 
other  DEH  and  Army  information  systems  but  also  must  be  able  to  satisfy  required 
interfaces  to  the  other  Army  information  systems. 

System  Security 

The  candidate  system  must  allow  various  levels  of  database  and  program 
security.  Access  to  various  system  levels  should  be  regulated  by  some  sort  of 
password  assigned  to  the  users. 

Distributed  Configuration 

The  proposed  system  must  be  capable  of  supporting  local  area  networks  with  a 
maximum  32-user  capacity  and  a  high-speed  (9,600-baud  or  greater)  link.  The 
proposed  system  must  have  a  remote  network  capability  of  linking  four  to  eight 
terminals  with  a  high-speed  (9,600  baud  or  greater)  link.  By  definition,  the 
distributed  configuration  assumes  a  simultaneous  interface  and  remote  printing 
capability  between  the  host  computer  application  and  the  distributed  processes. 

Required  Interfaces 

The  proposed  supply  management  system  must  be  capable  of  interfacing  with 
the  five  DEH  and  Army  management  information  systems  listed  below.  These 
interfaces  must  be  able  to  » eadily  transfer  data  and  the  information  structures  must 
be  compatible.  Interfaces  will  be  partly  judged  on  whether  information  can  be 
transferred  in  real  time  or  batch.  Candidate  systems  will  not  be  eliminated  from 
consideration  if  they  do  not  interface  with  the  following  systems,  but  the  lowest 
scores  will  be  given  to  those  candidate  systems  that  are  incapable  of  interfaces  and 
higher  scores  given  to  the  candidates  that  are  capable  of  these  interfaces.  Total 
compliance  means  that  exporyimport  routines  that  will  readily  transfer  the  required 
data  are  already  programmed. 

IFS-M 

Candidate  systems  must  be  capable  of  interfacing  with  the  IFS-M.  Since  IFS-M 
is  the  umbrella  system  under  which  the  supply  system  will  operate,  candidates  that 
cannot  interface  will  not  be  considered  further.  For  that  reason,  the  candidate 
system  must  operate  in  a  UNIX  or  disk  operating  system  (DOS)  environment.  IFS-M 


already  has  interfaces  programmed  to  the  other  Army  information  systems  and  can 
serve  as  a  gateway  between  them  and  the  supply  management  system.  However,  not 
all  Army  installations  are  implementing  IFS-M  and  these  interfaces  are  essential  for 
those  installations. 

Standard  Army  Automated  Contracting  System  (SAACONS) 

The  proposed  supply  management  system  must  be  capable  of  interfacing  with 
the  Army’s  proposed  automated  contracting  system,  SAACONS. 

Other  Supply  Information 

Interfaces  with  other  supply  information  systems  such  as  "Partmaster”  and/or 
"Haystack”  should  already  be  written. 

SAILS/SARSS 

The  candidate  systems  must  be  capable  of  interfacing  with  the  Standard  Army 
Intermediate  Level  Supply  (SAILS)  system  and  the  Standard  Army  Retail  Supply 
System  (SARSS)  or  their  successors. 

Finance  and  Accounting 

The  candidate  supply  management  system  must  be  able  to  export  the  required 
data  to  the  Army’s  finance  and  accounting  system. 

Platform  Independence 

Since  system  hardware  has  not  yet  been  determined,  the  candidate  system 
software  must  be  capable  of  operating  on  standard  mini-  or  microcomputers  (highly 
flexible  portability).  Also,  selecting  a  platform-independent  system  will  guarantee 
that  DEH  systems  maintain  an  open-architecture  environment  and  will  ensure  the 
system  remains  flexible.  Therefore,  the  candidate  system  mast  be  programmed  in 
portable  application  languages.  Platform  independence  also  assumes  that  the  system 
will  operate  under  a  normal  office  environment  with  little  renovation  for  heating, 
ventilating,  and  air  conditioning  (HVAC)  or  electrical  equipment.  Some  r  inor 
remodeling  may  be  necessary  fur  physical  security  of  the  system. 


Scanning  Capabilities 

The  proposed  engineering  supply  management  system  must  be  capable  of 
utilizing  current  and  future  scanning  technologies.  Systems  that  are  not  capable  of 
such  hardware  compatibility  are  not  flexible  enough  for  further  consideration.  How 
well  the  candidate  system  allo^'^s  scanning  inputs  dictates  the  score  they  receive  for 
the  following  categories. 

Bar-Code  Inputs 

The  proposed  system  must  be  capable  of  accepting  bar-code  inputs  either 
directly  from  bar-coding  hardware  or  downloaded  from  this  equipment  in  a  batch 
mode.  Bar  coding  will  be  extremely  important  for  most  aspects  of  material  receipt, 
issue,  and  inventory  control. 

Optical  Scanning  Equipment 

The  candidate  systems  should  be  able  to  accept  inputs  pertaining  to  order  issues 
and  order  receipts  from  optical  scanning  equipment. 

Imaging 

The  future  engineering  supply  management  system  must  be  capable  of  storing 
and  retrieving  electronically  stored  images.  Being  able  to  generate  pictures  —  on 
terminals  or  hard  copy  —  will  be  a  tremendous  advantage  to  the  engineering  supply 
operations. 

FUNCTIONAL  CRITERIA 

Report  Generating  and  Printing  Capabilities 

Given  the  infinitely  weighted  requirement  for  a  relational  database  and  SQL, 
the  system’s  ability  to  comply  with  any  single  reporting  requirement  would  be 
minimal.  Compliance  with  this  requirement  will  be  based  on  the  candidate  system’s 
ability  to  easily  search  and  sort  user-selected  elements  of  the  database  and  to 
generate  flexible  reports  such  as  supply  management  reports,  reorder  reports,  stock 
number  history  reports,  audit  transaction  reports,  overestimate  reports,  due-out/due- 
in  reports,  zero  balance  reports,  and  transfer  lists,  to  name  a  few. 


Stock  Control  Requirements 

The  proposed  engineering  supply  management  system  must  be  capable  of  the 
following  stock  control  functions. 

Expanded  Item  Identification 

The  system  should  have  an  expanded  item  identification  field  to  further  identify 
inventory  items.  Users  need  the  capability  to  search  for  inventory  items  by 
nomenclature,  part  number,  physical  characteristics,  and  substitute  items. 

Stock  Fund  War  ReservesIFreeze  Codes 

The  system  should  be  able  to  electronically  reserve  inventory  terns  tagged  for 
war  reserves  or  other  needs.  This  is  particularly  important  where  DEHs  share 
warehouse  space  and  need  inventory  dedicated  to  their  specific  requirements.  This 
will  ensure  materials  will  be  available  for  RPMA  when  needed. 

Catalog  File 

The  system  should  be  able  to  generate  an  up-to-date  catalog  of  all  inventoried 
items  including  quantities,  description,  substitutes,  location,  and  order  status.  The 
catalog  should  be  on-line  but  it  should  also  be  easy  to  generate  hard  copy. 

Replenishment  Capability 

The  proposed  system  must  be  capable  of  generating  an  inventory  replenishment 
on  demand  or  at  a  specified  reorder  point  using  any  accepted  economic  order  quantity 
(EOQ)  algorithm.  This  capability  should  be  easily  modified  to  satisfy  the  needs  of 
different  installations.  Inventory  control  should  consider  holding  costs,  ordering 
costs,  etc. 

Add/ Drops 

The  system  should  identify  items  of  inventory  that  should  be  added  as  stocked 
items  and  those  that  should  be  removed  from  stock  items  based  on  demand  or  other 
criteria. 


Physical  Inventory  Requirements 

The  proposed  engineering  supply  management  system  must  be  capable  of  the 
following  physical  inventory  functions. 

Cyclic  Inventories 

The  candidate  system  should  be  capable  of  inventorying  all  or  part  of  the 
material  in  the  warehouse  yearly  or  at  any  interval  at  the  discretion  of  the 
warehouse  managers. 

Inventory  Worksheet 

The  system  must  be  able  to  generate  inventory  worksheets  that  satisfy  different 
DEH  needs. 

Line-ltemI Dollar-  Value  Accounting 

The  system  must  be  able  to  count  inventory  by  line  item  or  accumulate  it  by 
dollar  value.  This  function  must  be  on-line  and  must  reflect  the  most  current 
information. 

Seasonal/Standby  Items 

The  proposed  system  must  be  able  to  handle  seasonal/standby  items  of 
inventory  in  addition  to  normal  demand  criteria. 

Spoilage/Aging  Inventory  Display 

The  system  should  be  capable  of  tracking  the  length  of  time  items  of 
inventory  —  individual  pieces  or  lots  —  have  been  in  the  system  to  determine  aging 
and  spoilage  of  those  items. 

Picking/Issuing  Requirements 

The  proposed  engineering  supply  management  system  must  be  capable  of 
performing  the  following  inventory  picking/issuing  functions. 

Creates  Pick  Documents 

The  system  must  be  able  to  generate  flexible  pick  documents  needed  by 
material  coordinators  and  shop  foremen. 
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Automatic  Material  Coordination  and  Equipment  Control 

Items  of  inventory  must  be  tracked  when  they  are  being  held  in  the  material 
coordination  area.  The  proposed  system  must  able  to  track  these  materials  at  storage 
sites,  maintain  data  issued  information,  and  keep  accountable  records.  It  must  keep 
those  records  separate  from  the  stock  fund  account. 

Automated  Issue/Return  Slips 

The  system  must  be  capable  of  handling  automated  issue/return  slips  such  as 
the  material  release  orders. 

Determining  Picking  Criteria 

The  system  must  be  capable  of  determining  the  criteria  for  picking  inventory 
and  planning  how  it  is  to  be  picked. 

Receiving/Putaway  Requirements 

The  proposed  engineering  supply  management  system  must  be  capable  of 
performing  the  following  inventory  receiving/putaway  functions. 

Generating  Storage  Documents 

The  system  must  generate  various  types  of  storage  documents  that  offer 
flexibility  to  individual  users. 

Hot  Tag  (Receipt/Issue) 

This  requirement  refers  to  the  ability  to  monitor  demand  of  items  that  have  yet 
to  be  received.  When  items  in  demand  are  received,  they  are  not  stored  but  are 
immediately  issued/shipped. 

Partial  Receipts 

The  system  must  be  able  to  handle  partial  receipt  of  ordered  material  and 
reconcile  the  quantity  received  versus  quantity  ordered. 

Automatic  Inventory  Update 

Inventory  levels  must  automatically  be  updated  as  inventory  is  received  and 
issued. 
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Discrepant  Material 

The  system  must  be  capable  of  reconciling  differences  in  material  received 
versus  material  ordered.  The  system  should  make  necessary  adjustments  to  stock 
files  and  process  paperwork  for  items  returned  to  the  wholesale  depot  or  local  vendor 
as  well  as  all  necessary  cost  accounts. 

Order  Processing  Requirements 

The  proposed  engineering  supply  management  system  must  be  capable  of 
performing  the  following  order  processing  functions. 

Transaction  Reversal  Capability 

The  system  must  be  capable  of  transaction  reversals  so  that  erroneous  entries  or 
changes  can  be  easily  corrected  while  on  line.  The  user  should  not  have  to  leave  the 
system  to  make  the  reversals,  but  transactions  should  be  recorded. 

Document  Register 

The  system  must  be  able  to  support  a  dynamic  electronic  log  of  documents  in  the 
system  that  contain  updated  transaction  status. 

Military  Standard  Requisitioning  and  Issue  Procedures 

The  system  must  support  both  current  and  future  military  standard 
requisitioning  and  issue  procedures  (MILSTRIP). 

Transaction  Register 

Candidate  systems  must  be  able  to  maintain  a  history  of  all  system  transactions 
and  must  be  able  to  support  an  audit  trail  of  such  transactions. 

Automatic  Purchase  Requisitions 

The  system  should  be  capable  of  generating  automatic  purchase  requisitions 
electronically  when  items  reach  their  reorder  point. 

Reconciliation 

The  system  must  be  capable  of  reconciling  open  orders  at  the  wholesale  level 
with  receipts  at  the  retail  level. 
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Job  Cost  by  Document.  Phase,  and/or  Facility 

The  system  must  be  able  to  collect  costs  by  document,  phase,  and/or  facility  and 
report  them  by  export  routines  to  other  systems  such  as  the  finance  and  accounting 
system  or  by  generating  hard-copy  management  reports.  The  system  must  be 
sophisticated  enough  to  allocate  costs  to  various  accounts  and  costing  structures. 
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SYSTEM  COMPl 


TABLE  B-1 

SYSTEMS  COMPLIANCI 


System  requirements 

Weight 

MEDSTOC 

APPMS 

AMCIS 

Technical  criteria 

On-liise  capability 

2 

S 

Required  database  marwiqement 
system 

Relational  database  SQL 

• 

0 

S 

3 

System  files  rruintersarKC 

• 

4 

S 

S 

Ease  of  use'self  help  capability 

0  143 

2 

4 

2 

Canrted  queries 

0  011 

4 

3 

4 

Oecumerrtation 

0  033 

4 

3 

4 

System  independerKe 

oon 

S 

S 

S 

System  security 

oo;4 

4 

4 

4 

Distributed  configuration 

• 

0 

S 

1 

Required  interfaces 

ITS  M 

• 

3 

4 

2 

SAACONS 

0  048 

3 

4 

4 

Other  supply  information 

0019 

3 

3 

4 

SAILVSARSS 

0  007 

4 

4 

4 

Firsarne  and  accountir>9 

0  IJ6 

4 

4 

4 

Platform  irsdependence 

0  3b8 

0 

s 

0 

Scannirtg  capabilities 

tar -code  inputs 

0  028 

1 

s 

4 

Optical  scannirtq  equipment 

0  028 

1 

2 

1 

Ima9(r>q 

0  083 

1 

2 

1 

Weighted  total 

1  63 

4  18 

1  98 

Functional  criteria 

■ 

■ 

Report  gonerating  and  printing 

0  03S 

capabilities 

Stocii  control  requirements 

■■ 

■ 

H 

Eapanded  item  identification 

0  022 

Stock  fund  urar  reserve^lreeie 

0  01 

codes 

Catalog  fik 

0  1 14 

D 

Replentshmeni  capability 

0  093 

o 

Add/drops 

0  021 

■ 

1 

Mof«.  At!  d<fonymv  are  defined  on  p  B-4 
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SUMMARY 


TABLE  B-1 


SYSTEMS  COMPLIANCE  SUMMARY  (Continued) 


Score 

System  requirements 

Weight 

MEOSTOC 

APPMS 

AMCISS 

BOSS 

WIS 

CASTLE 

CEMAS 

SBSS 

EPOS 

FESS 

SARSS 

Physical  inventory  requirements 

■ 

Cyclic  inventories 

0  0C.1 

-1 

/ 

s 

b 

b 

b 

b 

0 

1 

b 

inventory  worksheet 

0  o;*) 

1 

b 

4 

J 

b 

4 

H 

b 

4 

Lirse  itemrdollar  value  accounting 

G  O^b 

4 

b 

b 

4 

b 

4 

B 

b 

b 

Seasonal  standby  items 

GCU 

b 

1 

b 

b 

1 

4 

2 

B 

1 

b 

Spoilage  agirtg  inventory  display 
Pickirsgiissuirsg  requirements 

0  001 

b 

1 

b 

1 

1 

4 

1 

3 

1 

b 

Creates  pick  documents 

C  00/ 

1 

4 

4 

1 

b 

4 

4 

b 

b 

Automatic  rnattrtal  coordination 
arsd  equipnrsent  control 

C  Oi'b 

/ 

1 

1 

1 

2 

; 

3 

1 

1 

1 

Automated  issue  return  slips 

0  0*5^ 

} 

1 

.1 

1 

1 

b 

1 

2 

3 

4 

Determining  pickirsg  criteria 

a  001 

1 

2 

1 

1 

1 

1 

1 

1 

1 

Re<eivir>g.putaway  requirements 

Oerseratirsg  storage  documents 

00'' 

4 

) 

4 

4 

1 

4 

3 

b 

b 

Hot  tag  (receipt  issue) 

0  O' 

S 

b 

b 

4 

3 

3 

4 

1 

3 

3 

Partial  receipts 

GO'S 

4 

1 

4 

4 

3 

4 

4 

4 

1 

b 

Automatic  inventory  update 

0  04b 

S 

b 

4 

b 

4 

b 

b 

b 

b 

b 

Discrepant  material 

0  004 

s 

2 

4 

2 

1 

4 

3 

4 

1 

4 

Order  processing  requirements 

Transaction  reversal  capability 

0  0  V 

'S 

b 

4 

4 

b 

b 

4 

4 

1 

b 

Document  register 

C  00b 

A 

b 

4 

4 

4 

b 

4 

4 

1 

b 

MiCSntiP  procedures 

0  0's? 

s 

4 

b 

1 

b 

4 

4 

b 

b 

Transaction  register 

0  0?4 

4 

b 

b 

4 

4 

b 

b 

b 

3 

Automatic  purchase  requisitions 

0  Obi 

I 

1 

4 

1 

3 

3 

4 

1 

4 

Reconciliation 

C  00<( 

4 

1 

4 

4 

1 

4 

2 

3 

1 

3 

Job  cost  by  document,  phase,  and  or 
facility 

0  ;bb 

t 

2 

4 

4 

2 

4 

4 

3 

4 

2 

Weighted  toul 

1  ?4 

2  92 

4  ;b 

4  19 

2  b/ 

4  20 

3  /9 

0  00 

3bl 

3  68 

3  89 

Note  MtDStOC  =  MetJu-di  Sy^ter^  appmS  =  Ajiomdied  ^erw>Aa>  P^openy  Mdndgemem  Syiiern,  AMCiSS  ®  AMC  invtdllaiion  Supply  System, 

HOSS  2  Hdse  Operdtiuos  SupDon  System  Wis  =  Ajrehouse  in,(enio^y  Control  System.  CASIit  =  Compute^  Aided  Supply  Ifdnsaciions.  logistics  tnwironment. 
CtMAS  =  CiviU  ngmeer  nvj  Matet^idi  Acquisition  Syste"'  S8SS  *  Standard  Base  Supply  System.  IPOS  2  fiectronic  Pomt-ol  Sale,  KSS  *  Facility  t ngmeering  Supply 
System,  i»S  M  =  integrated  lavility  System  wm,  Micro  SQi  =  Starsdard  Query  Language  SAACONS  *  Standard  Army  Automated  Contracting  System. 
SAiiS  2  Standard  Army  intermediate  I  eve' Supply  SAKSS  2  Standard  Army  Ketaii  Supply  System  MilSIRiP  *  military  standard  requisitioning  and  issue  procedure 
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ESTIMATED  MODIFICATION  EFFORT  (MAN-DAYS) 


TABLE  C-1 

ESTIMATED  MODIFICATION  EFFORT 
(Man-days) 


System  requirements 

Score 

APPMS 

AMCISS 

BOSS 

WIS 

CASTLE 

EPOS 

FESS 

SARSS 

Technical  criteria 

On-line  capability 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Required  database 

management  system 

Relational  database/SQL 

Pass 

Fail 

Fail 

Pass 

Pass 

Fail 

Pass 

Pass 

System  files  maintenance 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Pass 

Ease  of  use/setf-help 

22 

88 

88 

33 

0 

22 

132 

66 

capability 

Canned  queries 

22 

44 

44 

22 

22 

22 

22 

22 

Documentation 

22 

66 

66 

22 

22 

44 

66 

132 

System  independence 

0 

0 

0 

0 

0 

0 

0 

0 

System  security 

6 

22 

22 

6 

0 

1 1 

0 

11 

Distributed  configuration 

Pass 

Fail 

Fail 

Pass 

Pass 

Pass 

Pass 

Pass 

Required  interfaces 

44 

132 

198 

44 

0 

88 

132 

22 

IFS-M 

Pass 

Fail 

Pass 

Pass 

Pass 

Fail 

Pass 

SAACONS 

- 

- 

- 

- 

- 

- 

- 

- 

Other  supply  information 

- 

- 

- 

- 

- 

- 

- 

- 

SAILS/SAARS 

- 

- 

- 

- 

- 

- 

- 

- 

Finance  and  accounting 

- 

- 

- 

- 

- 

- 

- 

- 

Platform  independence 

0 

0 

0 

0 

0 

0 

0 

0 

Scanning  capabilities 

Bar-code  inputs 

0 

66 

66 

0 

0 

0 

44 

0 

Optical  scanning 
equipment 

44 

88 

88 

44 

22 

22 

44 

88 

Imaging 

66 

132 

132 

66 

44 

66 

88 

132 

Technical  effort 

226 

638 

704 

237 

no 

275 

1 

528 

473 

Note  All  acronyms  are  det'n«i  on  cwge  C  -S.  columns  may  not  add  due  to  rounding 
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TABLE  C-1 


ESTIMATED  MODIFICATION  EFFORT  (Continued) 
(Man-days) 


Score 

System  requirements 

APPMS 

AMCISS 

BOSS 

WIS 

CASTLE 

EPOS 

FESS 

SARSS 

Functional  criteria 

Report  generating  and 
printing  capabilities 

0 

88 

132 

22 

0 

33 

44 

0 

Stock  control  requirements 

Expanded  item 
identification 

6 

44 

0 

6 

6 

1 1 

66 

0 

Stock  fund  war 
reserwes/freeze  codes 

6 

0 

0 

6 

0 

6 

1 1 

0 

Catalog  file 

1 1 

66 

66 

1 1 

0 

44 

66 

44 

Replenishment  capability 

22 

44 

0 

22 

1 

6 

1 1 

0 

Add/drops 

Physical  inventory  require¬ 
ments 

1  1 

0 

0 

6 

1 

6 

11 

0 

Cyclic  inventories 

44 

0 

0 

6 

0 

0 

44 

0 

Inventory  worksheet 

6 

0 

22 

6 

0 

11 

0 

11 

Line-item/dollar-value 

11 

0 

11 

n 

accounting 

Seasonal/standby  items 

11 

0 

0 

6 

0 

0 

1 1 

0 

Spoilage/aging  inventory 
display 

1 1 

0 

66 

17 

6 

17 

22 

0 

Picking/issuing  requirements 

Creates  pick  documents 

33 

66 

66 

22 

6 

33 

66 

66 

Automatic  material  coordi¬ 
nation  and  equipment 
control 

- 

- 

- 

- 

Automated  issue/return  slips 

- 

- 

- 

- 

- 

- 

- 

Determining  picking  criteria 

- 

- 

- 

- 

- 

- 

- 

- 

Receiving/putaway 

requirements 

22 

88 

88 

22 

1 1 

44 

66 

22 

Generating  storage 
documents 

Hot  tag  (receipt/issue) 

- 

- 

- 

- 

- 

- 

- 

- 

Partial  receipts 

- 

- 

- 

- 

- 

- 

_ 

- 

Automatic  inventory  update 

- 

- 

- 

- 

- 

- 

- 

- 

Discrepant  material 

- 

~ 

- 

- 

“ 

- 

- 

Wof®  All  dcronvm^  are  denned  on  pdyt?  C  S  coiumn>  may  not  add  due  lo  roundmg 
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TABLE  C-1 


ESTIMATED  MODIFICATION  EFFORT  (Continued) 
(Man-days) 


Score 

System  requirements 

APPMS 

AMCISS 

BOSS 

WIS 

CASTLE 

EPOS 

FESS 

SARSS 

Order  processing  requirements 

Transaction  reversal 
capability 

0 

22 

22 

0 

0 

11 

44 

0 

Document  register 

0 

1 1 

1 1 

6 

0 

6 

33 

0 

MILSTRIP  procedures 

1  1 

0 

0 

22 

0 

1 1 

0 

0 

Transaction  register 

0 

0 

11 

6 

0 

0 

0 

22 

Automatic  purchase 
requisitions 

1 1 

22 

44 

1 1 

6 

1 1 

44 

11 

Reconciliation 

6 

11 

1 1 

6 

0 

1 1 

33 

22 

Job  cost  by  document,  phase, 
and/or  facility 

1 1 

22 

22 

11 

0 

22 

44 

44 

Functional  effort 

231 

484 

561 

220 

35 

281 

616 

242 

Total  modification  r  jrt 

457 

1.122 

1.265 

_ 

457 

145 

556 

1,144 

715 

MtOSTOC  »  Stock  Control  Systen^,  fiPPMS  s  Automated  Persona*  Property  Management  System.  AMC'SS  *  AMC  inytaiiation  Supply  System, 

BOSS  *  Base  Operations  Suppon  System.  WiS  *  Warehouse  inventory  Control  System.  CaSIU  *  Compoter  Aided  Supply  Iransaatons.  logistics  fcnvironmenis, 
CkMAS  «  Civil  Engineering  Matenai  Acquisition  System.  S0S^  *  Standard  Base  Supply  System.  EPOS  *  Electronic  Point  ©♦  Sale,  EtSS  *  facility  Engineering  Supply 
System  ifS-M  *  integrated  Facility  System-Mmi/Micro  SQi  =  Standard  Query  language.  SAACONS  *  Standard  Army  Automated  Contraciirig  System, 
SAKS  »  Standard  Army  intermediate  $  evpi  Supply.  SAHSS  x  Standard  Army  Retail  Supply  System  MkSTHiP  *  military  standard  requisitioning  and  issue  procedure 
Columns  "'ay  not  add  due  to  rounding 
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GLOSSARY 


ABECAS 

Argos  Business  Enterprise  Cost  Accounting  System 

AHP 

=r 

analytic  hierarchical  process 

AMC 

Army  Materiel  Command 

AMCISS 

Army  Materiel  Command  Installation  Supply  System 

ANSI 

American  National  Standards  Institute 

APPMS 

Automated  Personal  Property  Management  System 

Ascn 

= 

American  Standard  Code  for  Information  Interchange 

ASIMS 

Army  Standard  Information  Management  System 

BCE 

= 

Base  C:  vil  Engineer 

BOSS 

= 

Base  Operations  Support  System 

CASCOM 

= 

Combined  Arms  Support  Command 

CASTLE 

= 

Computer-Aided  Supply  Transactions,  Logistics  Environment 

CEMAS 

= 

Civil  Engineering  Material  Acquisition  System 

CERL 

= 

Construction  Engineering  Research  Laboratory 

COBOL 

common  business  oriented  language 

DEH 

= 

Directorate  of  Engineering  and  Housing 

DLA 

z= 

Defense  Logistics  Agency 

DoD 

= 

Department  of  Defense 

DOL 

= 

Directorate  of  Logistics 

DOS 

disk  operating  system 

EOQ 

— 

economic  order  quantity 

EPOS 

— 

Electronic  Point  of  Sale 

FEJ  E 

z=. 

Facilities  Engineering  Job  Estimating  System 

D-3 


FESS 

— 

Facilities  Engineering  Supply  System 

HSC 

= 

Health  Services  Command 

IBM 

International  Business  Machines 

IFDEP 

Integrated  Facilities  Data  Entry  Process 

IFS-M 

= 

Integrated  Facilities  System-Mini/Micro 

LMI 

Logistic  Management  Institute 

MEDSTOC 

= 

Medical  Stock  Control  System 

MILSTRIP 

= 

Military  Standard  for  Requisitioning  and  Issue  Procedures 

PC 

personal  computer 

RFP 

request  for  proposals 

RPMA 

= 

real  property  maintenance  activity 

SAACONS 

Standard  Army  Automated  Contracting  System 

SARSS 

= 

Standard  Army  Retail  Supply  System 

SBSS 

Standard  Base  Supply  System 

SQL 

= 

standard  query  language 

SAILS 

Standard  Army  Intermediate  Level  Supply  System 

STANFINS 

= 

Standard  Army  Financial  System 

USAEHSC 

U.S.  Army  Engineering  and  Housing  Support  Center 

WIS 

Warehouse  Inventory  Control  System 
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